[AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
Adam Roach via Datatracker <noreply@ietf.org> Wed, 16 October 2019 05:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10312087E; Tue, 15 Oct 2019 22:55:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-payload-rtp-ttml@ietf.org, Roni Even <roni.even@huawei.com>, avtcore-chairs@ietf.org, roni.even@huawei.com, avt@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.105.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach <adam@nostrum.com>
Message-ID: <157120533756.28095.10649811061659847293.idtracker@ietfa.amsl.com>
Date: Tue, 15 Oct 2019 22:55:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/vUDsvJv117o2JmMsvt7jhtwbICs>
Subject: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 05:55:50 -0000
Adam Roach has entered the following ballot position for draft-ietf-payload-rtp-ttml-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work everyone put into this document. I think it's not quite ready to publish, due to one ambiguity, one critical missing feature, and the lack of guidance around fragmentation. I also have two comments that I consider very important, although they don't quite rise to the level of blocking publication. As always, it's possible that my DISCUSS points are off-base, and I'd be happy to be corrected if I've misunderstood anything here. --------------------------------------------------------------------------- §4.1: > When the document spans more > than one RTP packet, the entire document is obtained by > concatenating User Data Words from each contributing packet in > ascending order of Sequence Number. This is underspecified, in that it doesn't make it clear whether it would be valid to split a single UTF-8 or UTF-16 character between RTP packets, and it is nearly certain that different implementations will make different assumptions on this point, leading to interop failures. For example, the UTF-8 encoding of '¢' is 0xC2 0xA2. Would it be valid to place the "0xC2" in one packet and the "0xA2" in a subsequent packet? Without specifying this, it is quite likely that some implementations will use, e.g., UTF-8 strings to accumulate the contents of RTP packets; and most such libraries will emit errors or exhibit unexpected behavior if units of less than a character are added at any time. (The same point holds for splitting a UTF-16 byte across packets). I don't think it much matters which choice you make (explicitly allowing or explicitly forbidding splitting characters between packets), but it does need to be explicit. I have a slight personal preference for requiring that characters cannot be split (both for ease of implementation on the receiving end and to more smoothly handle missing data due to extended packet loss), but leave it to the authors and working group to decide. --------------------------------------------------------------------------- Unlike other definitions to convey non-loss-resilient data on RTP streams, this document had no defined mechanism to deal with packet loss. This makes it unusable on the public Internet, where packet loss is an inevitable feature of the network. The existing text-in-RTP specifications define procedures to deal with such loss (see, e.g., RFC 4103 section 4 and RFC 4396 section 5). --------------------------------------------------------------------------- This format is rather unique in that it, alone among all other RTP text formats, is designed to send monolithic documents that may stretch into the multiple kilobyte range. While fragmentation is mentioned as a possibility, the document provides no implementation guidance about when to fragment documents, and what sizes each fragment should assume. RFC 4396 section 4.4 is an example of the kind of information I would expect to see in a document like this, with emphasis on the fact that TTML documents are going to frequently exceed the PTMU for a typical network connection. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §1: > TTML (Timed Text Markup Language)[TTML2] is a media type for > describing timed text such as closed captions (also known as > subtitles) in television workflows or broadcasts as XML. Although superficially similar, there are important distinctions between subtitles (intended to help a hearing audience exclusively with spoken dialog, typically because the audio is in a different language or otherwise difficult to understand) and closed captions (intended to aid deaf or hard-of-hearing viewers by providing a direct, word-for-word transcription of dialog as well as descriptions of all other audio present). Calling one "also known as" the other is incorrect. I suggest rephrasing as: TTML (Timed Text Markup Language)[TTML2] is a media type for describing timed text such as closed captions and subtitles in television workflows or broadcasts as XML. --------------------------------------------------------------------------- §4.2.1.1: > The TTML document instance MUST use the "media" value of the > "ttp:timeBase" parameter attribute on the root element. This statement makes an assumption that the "http://www.w3.org/ns/ttml#parameter" namespace MUST be mapped to the "ttp" prefix, which is both bad form and probably not what is intended. I suggest rephrasing as: The TTML document instance MUST include a "timeBase" element from the "http://www.w3.org/ns/ttml#parameter" namespace containing the value "media".
- [AVTCORE] Adam Roach's Discuss on draft-ietf-payl… Adam Roach via Datatracker
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Roni Even (A)
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Roni Even (A)
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Roni Even (A)
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Christer Holmberg
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Christer Holmberg
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Adam Roach
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… James Sandford
- Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-… Adam Roach