Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

James Sandford <james.sandford@bbc.co.uk> Tue, 19 November 2019 16:35 UTC

Return-Path: <james.sandford@bbc.co.uk>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E190912094C; Tue, 19 Nov 2019 08:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVFIZgBL0GFs; Tue, 19 Nov 2019 08:35:44 -0800 (PST)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2996120971; Tue, 19 Nov 2019 08:35:00 -0800 (PST)
Received: from BGB01XI1010.national.core.bbc.co.uk (bgb01xi1010.national.core.bbc.co.uk [10.161.14.14]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id xAJGYqbc020289; Tue, 19 Nov 2019 16:34:52 GMT
Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1010.national.core.bbc.co.uk ([10.161.14.14]) with mapi id 14.03.0408.000; Tue, 19 Nov 2019 16:34:52 +0000
From: James Sandford <james.sandford@bbc.co.uk>
To: Adam Roach <adam@nostrum.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "Roni Even (A)" <roni.even@huawei.com>, The IESG <iesg@ietf.org>
CC: "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "draft-ietf-payload-rtp-ttml@ietf.org" <draft-ietf-payload-rtp-ttml@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
Thread-Index: AQHVhCrYYQgw8vTQ/0WeIklAJNo2wKddToqQgAAA3yf///XnAIAidBzqgACqd4CAEoHzwA==
Date: Tue, 19 Nov 2019 16:34:52 +0000
Message-ID: <734752AF0E88364D983373FE5CEFED577E78A0E0@bgb01xud1001>
References: <F8AA26D8-8577-4609-ADEF-714EA7607BA0@ericsson.com> <734752AF0E88364D983373FE5CEFED5770DE3F1D@bgb01xud1001> <734752AF0E88364D983373FE5CEFED5770DE3F2D@bgb01xud1001> <737589BC-1F0A-4B78-AA0B-C00445F01B66@ericsson.com> <734752AF0E88364D983373FE5CEFED5771CAB2FB@bgb01xud1001>, <abcfb49b-124c-1bf3-1103-55b830fa5641@nostrum.com>
In-Reply-To: <abcfb49b-124c-1bf3-1103-55b830fa5641@nostrum.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.185.132.13]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24054.007
x-tm-as-result: No-31.898900-8.000000-10
x-tmase-matchedrid: IeZYkn8zfFq7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p1pHA4vzDv2iu8k e9FM2hzh0LanOvpsZ3gt9fn3fss4EeAZjtJaH9BxsU+l9160C1OeNCy0ubpK/Wmj1qXcLu1iRmk sNu/RZSrtqnSOTSwVrBcRpPm6GTDMQgUInkqQBs+ZroPNdqiG8xkqnRJng/51DXHJBD8X89iD/m A2vw4bvWfg252M3FZQbsfJNPWIq47WkoCSz3pU5vvADvTnCf5v2B5g90ltSFZXPwnnY5XL5BwAl HA73Fsg6wiDhzBhrdubQtisRA6ZvipFy4tGHuSTsTcWkxuDrdIxmbT6wQT2a4fAYSb4KlgZTxOe CUUj4KuKb7YRyHEK7qBRTaiW3vK1ni0W1YoG9GnThGbP9qB93ClayzmQ9QV0grAXgr/AjP2NBq1 Ze9/6Y1It3twV1phfhL6MANw66tGiT190luQ/K0g5Iem1vm3HUd7Bjfo+5jQcVJCT3tVgai0PS8 Vog/A/6Gl0AUzE2MJEQfoWZDUvaOW/w3RP+xtRV6uR7UoeQuQppGYMKZezNxi9RS/27dWNgST/J 9Kk1nGwkvvbYkc0LGQXNvmm1yUAVAJs3L2kUff8sslxtZarKO7sedMuEdnYPi2WkVF4xvvSO1vr 6DJ96lqzI2BdWtMePG3yXXjqWX5dxPzWu+SkNMNrWpY804TGlWXxvHK+rV6oJRU5bgCqD0bk0r+ pQpSDhTLAI0K6AvXSpEU3/ItJHSTtChVcJtE4j5hLPCX3ZdN5y+Nu7/EOOmsSgW01iDQL1eK56c +dVwF2L7tj2Zl0Xk7h+KM/Z2sVEZG6oCaQzfaeAiCmPx4NwFkMvWAuahr8eFIQTy0Zb4asImbyV LytewtuKBGekqUpPjKoPgsq7cA=
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--31.898900-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24054.007
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/uXPXUTta6nSrbR_DGhoYtIAK-NQ>
Subject: Re: [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
Precedence: list
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: Tue, 19 Nov 2019 16:35:47 -0000

Hello,
Version 06 has now been submitted. I believe this resolves the outstanding comments from Adam and Christer.

https://www.ietf.org/id/draft-ietf-payload-rtp-ttml-06.html

Regards,
James

==========
James Sandford
R&D Project Engineer

BBC Research and Development
5th Floor
Dock House
MediaCityUK
Salford
M50 2LH

Tel: 030304 (09549)
Web: http://www.bbc.co.uk/rd

________________________________________
From: Adam Roach [adam@nostrum.com]
Sent: 07 November 2019 21:55
To: James Sandford; Christer Holmberg; Roni Even (A); The IESG
Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf.org
Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

Thanks for the nudge. These changes address my DISCUSS points. The only
comment I would make on the new text is that it uses "MTU" (which
usually implies local segment MTU) in several places where "Path MTU" is
intended.

I have updated my position from "DISCUSS" to "YES." Thanks again for
your work.

/a

On 11/7/19 5:46 AM, James Sandford wrote:
> Sorry to chase up. Have you had a chance to check if the current version addresses your concerns, Adam?
>
> Regards,
> James
>
> ==========
> James Sandford
> R&D Project Engineer
>
> BBC Research and Development
> 5th Floor
> Dock House
> MediaCityUK
> Salford
> M50 2LH
>
> Tel: 030304 (09549)
> Web: http://www.bbc.co.uk/rd
>
> ________________________________________
> From: Christer Holmberg [christer.holmberg@ericsson.com]
> Sent: 16 October 2019 15:37
> To: James Sandford; Roni Even (A); Adam Roach; The IESG
> Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf.org
> Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
> Hi,
>
>>   Sorry. I'm getting confused here. Re-reading, it's using RFC2198 and expanding on it's use. I read section 4.2 as an alternative method where no extra headers are required and it works purely on identifying matching sets of data via other means and counting back from the final packet to match Sequence Numbers.
> RFC2198 uses a separate payload type for the redundant data.
>
> Section 4.2.1.1 of the rtp-ttml draft says:
>
>     "Multiple TTML subtitle streams MUST NOT be interleaved in a single RTP stream."
>
> I can't find any technical reason for that MUST NOT (it would be good to add it), so I don't know whether using multiple payload types is going to be a problem, but just to keep in mind.
>
> Regards,
>
> Christer
>
>
>
>
>
>      ==========
>      James Sandford
>      R&D Project Engineer
>
>      BBC Research and Development
>      5th Floor
>      Dock House
>      MediaCityUK
>      Salford
>      M50 2LH
>
>      Tel: 030304 (09549)
>      Web: http://www.bbc.co.uk/rd
>
>      ________________________________________
>      From: James Sandford [james.sandford@bbc.co.uk]
>      Sent: 16 October 2019 15:11
>      To: Christer Holmberg; Roni Even (A); Adam Roach; The IESG
>      Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf.org
>      Subject: RE: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>      I'm referring to the method in Section 4.2 of RFC 4103 that requires no extra headers.
>
>      James
>
>      ==========
>      James Sandford
>      R&D Project Engineer
>
>      BBC Research and Development
>      5th Floor
>      Dock House
>      MediaCityUK
>      Salford
>      M50 2LH
>
>      Tel: 030304 (09549)
>      Web: http://www.bbc.co.uk/rd
>
>      ________________________________________
>      From: Christer Holmberg [christer.holmberg@ericsson.com]
>      Sent: 16 October 2019 15:06
>      To: James Sandford; Roni Even (A); Adam Roach; The IESG
>      Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf.org
>      Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>      Hi,
>
>      >    Sorry. I think I am mixing terms here. RFC 4396 specifies redundant transmission by default.
>      >
>      >    You are right that the RFC4103 method will work in our case with minimal changes.
>
>      When you say "RFC4103 method", do you refer the method where the primary and redundancy data is transported in the *same* RTP packet, using the same payload type, as the primary data? RFC4103 also defines usage of the RFC2198 method, so just to make sure what you refer to.
>
>      Regards,
>
>      Christer
>
>
>
>          ________________________________________
>          From: Roni Even (A) [roni.even@huawei.com]
>          Sent: 16 October 2019 14:42
>          To: James Sandford; Adam Roach; The IESG
>          Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.org; avt@ietf..org
>          Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>          Hi James,
>          RTCP is mandatory for RTP, in the case of packet loss how will you ask for retransmission since RTP is unidirectional.  I did not see that RFC4396 mention uni-directional re-transmission.
>          If you are not using retransmission, packet loss will require FEC or redundancy , so you will need to specify how to use them.
>          For redundancy look at RFC4103 for addressing the sequence number  and RFC2198
>
>          Roni Even
>
>          -----Original Message-----
>          From: James Sandford [mailto:james.sandford@bbc.co.uk]
>          Sent: Wednesday, October 16, 2019 4:23 PM
>          To: Roni Even (A); Adam Roach; The IESG
>          Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.org; avt@ietf..org
>          Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>          Doesn't RFC4588 require RTCP? That might be a bit over the top for a minimal implementation. RFC 4396 references RFC4588 (all be it in a draft state) while also providing a basic uni-directional re-transmission scheme as the default.
>
>          ==========
>          James Sandford
>          R&D Project Engineer
>
>          BBC Research and Development
>          5th Floor
>          Dock House
>          MediaCityUK
>          Salford
>          M50 2LH
>
>          Tel: 030304 (09549)
>          Web: http://www.bbc.co.uk/rd
>
>          ________________________________________
>          From: Roni Even (A) [roni.even@huawei.com]
>          Sent: 16 October 2019 14:18
>          To: James Sandford; Adam Roach; The IESG
>          Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.org; avt@ietf..org
>          Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>          Hi James,
>          About packet loss, If the intention is to use retransmission look at RFC4588, it encapsulate the original RTP so no need for changes in ttml. You just need to signal support in the SDP.
>
>          Roni Even
>
>          -----Original Message-----
>          From: James Sandford [mailto:james.sandford@bbc.co.uk]
>          Sent: Wednesday, October 16, 2019 3:45 PM
>          To: Adam Roach; The IESG
>          Cc: draft-ietf-payload-rtp-ttml@ietf.org; Roni Even (A); avtcore-chairs@ietf.org; avt@ietf.org
>          Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
>
>          Responses in-line.
>
>          Regards,
>          James
>
>          >----------------------------------------------------------------------
>          >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.
>
>          Thanks for highlighting this. I also have a slight preference for not splitting characters.
>
>          >-----------------------------------------------------------------------
>          >----
>          >
>          >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).
>
>          I think RFC 4396 Section 5 could be adapted for our purposes. The main issue is the TTML payload document currently makes use of the Sequence Number to identify the order of document fragments. A re-transmitted fragment would have a different Sequence Number so there would be no way to match equivalent packets. A potential solution is to use the 16 Reserved bits for a new counter that performs the task of identifying fragment order.
>
>          How would this affect the progress of this document? While it represents a major change to the layout of the payload, the mechanisms used will be identical.
>
>          >-----------------------------------------------------------------------
>          >----
>          >
>          >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.
>
>          I would not be opposed to an equivalent section to this. I'll work on adapting the referenced section.
>
>          >----------------------------------------------------------------------
>          >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.
>
>          This isn't strictly true. At least in the UK, the term subtitles is used as a catch-all term to describe both translation subtitles/those to support unintelligible speech, and subtitles for the deaf and hard of hearing. That said, I have no objection to the alternative wording.
>
>          >-----------------------------------------------------------------------
>          >----
>          >
>          >§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".
>
>          I have spoken to Nigel Megitt (chair of the W3C Timed Text Working Group) about this. He noted that "timeBase" is an attribute not an element. The following alternative is verbose but unambiguous:
>
>              The TTML document instance's root "tt" element in the "http://www.w3.org/ns/ttml" namespace MUST include a "timeBase" attribute in the "http://www..w3.org/ns/ttml#parameter" namespace containing the value "media".
>
>          _______________________________________________
>          Audio/Video Transport Core Maintenance
>          avt@ietf.org
>          https://www.ietf.org/mailman/listinfo/avt
>
>
>
>