Return-Path: 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 To: Adam Roach , Christer Holmberg , "Roni Even (A)" , "The IESG" CC: "avtcore-chairs@ietf.org" , "draft-ietf-payload-rtp-ttml@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: <734752AF0E88364D983373FE5CEFED5770DE3F1D@bgb01xud1001> <734752AF0E88364D983373FE5CEFED5770DE3F2D@bgb01xud1001> <737589BC-1F0A-4B78-AA0B-C00445F01B66@ericsson.com> <734752AF0E88364D983373FE5CEFED5771CAB2FB@bgb01xud1001>, In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 16:35:47 -0000 Hello,=0A= Version 06 has now been submitted. I believe this resolves the outstanding = comments from Adam and Christer.=0A= =0A= https://www.ietf.org/id/draft-ietf-payload-rtp-ttml-06.html=0A= =0A= Regards,=0A= James=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= James Sandford=0A= R&D Project Engineer=0A= =0A= BBC Research and Development=0A= 5th Floor=0A= Dock House=0A= MediaCityUK=0A= Salford=0A= M50 2LH=0A= =0A= Tel: 030304 (09549)=0A= Web: http://www.bbc.co.uk/rd=0A= =0A= ________________________________________=0A= From: Adam Roach [adam@nostrum.com]=0A= Sent: 07 November 2019 21:55=0A= To: James Sandford; Christer Holmberg; Roni Even (A); The IESG=0A= Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf= .org=0A= Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttml-= 03: (with DISCUSS and COMMENT)=0A= =0A= Thanks for the nudge. These changes address my DISCUSS points. The only=0A= comment I would make on the new text is that it uses "MTU" (which=0A= usually implies local segment MTU) in several places where "Path MTU" is=0A= intended.=0A= =0A= I have updated my position from "DISCUSS" to "YES." Thanks again for=0A= your work.=0A= =0A= /a=0A= =0A= On 11/7/19 5:46 AM, James Sandford wrote:=0A= > Sorry to chase up. Have you had a chance to check if the current version = addresses your concerns, Adam?=0A= >=0A= > Regards,=0A= > James=0A= >=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= > James Sandford=0A= > R&D Project Engineer=0A= >=0A= > BBC Research and Development=0A= > 5th Floor=0A= > Dock House=0A= > MediaCityUK=0A= > Salford=0A= > M50 2LH=0A= >=0A= > Tel: 030304 (09549)=0A= > Web: http://www.bbc.co.uk/rd=0A= >=0A= > ________________________________________=0A= > From: Christer Holmberg [christer.holmberg@ericsson.com]=0A= > Sent: 16 October 2019 15:37=0A= > To: James Sandford; Roni Even (A); Adam Roach; The IESG=0A= > Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ie= tf.org=0A= > Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rtp-ttm= l-03: (with DISCUSS and COMMENT)=0A= >=0A= > Hi,=0A= >=0A= >> Sorry. I'm getting confused here. Re-reading, it's using RFC2198 and e= xpanding 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 S= equence Numbers.=0A= > RFC2198 uses a separate payload type for the redundant data.=0A= >=0A= > Section 4.2.1.1 of the rtp-ttml draft says:=0A= >=0A= > "Multiple TTML subtitle streams MUST NOT be interleaved in a single R= TP stream."=0A= >=0A= > 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 b= e a problem, but just to keep in mind.=0A= >=0A= > Regards,=0A= >=0A= > Christer=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= > James Sandford=0A= > R&D Project Engineer=0A= >=0A= > BBC Research and Development=0A= > 5th Floor=0A= > Dock House=0A= > MediaCityUK=0A= > Salford=0A= > M50 2LH=0A= >=0A= > Tel: 030304 (09549)=0A= > Web: http://www.bbc.co.uk/rd=0A= >=0A= > ________________________________________=0A= > From: James Sandford [james.sandford@bbc.co.uk]=0A= > Sent: 16 October 2019 15:11=0A= > To: Christer Holmberg; Roni Even (A); Adam Roach; The IESG=0A= > Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; a= vt@ietf.org=0A= > Subject: RE: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rt= p-ttml-03: (with DISCUSS and COMMENT)=0A= >=0A= > I'm referring to the method in Section 4.2 of RFC 4103 that requires= no extra headers.=0A= >=0A= > James=0A= >=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= > James Sandford=0A= > R&D Project Engineer=0A= >=0A= > BBC Research and Development=0A= > 5th Floor=0A= > Dock House=0A= > MediaCityUK=0A= > Salford=0A= > M50 2LH=0A= >=0A= > Tel: 030304 (09549)=0A= > Web: http://www.bbc.co.uk/rd=0A= >=0A= > ________________________________________=0A= > From: Christer Holmberg [christer.holmberg@ericsson.com]=0A= > Sent: 16 October 2019 15:06=0A= > To: James Sandford; Roni Even (A); Adam Roach; The IESG=0A= > Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; a= vt@ietf.org=0A= > Subject: Re: [AVTCORE] Adam Roach's Discuss on draft-ietf-payload-rt= p-ttml-03: (with DISCUSS and COMMENT)=0A= >=0A= > Hi,=0A= >=0A= > > Sorry. I think I am mixing terms here. RFC 4396 specifies redun= dant transmission by default.=0A= > >=0A= > > You are right that the RFC4103 method will work in our case wit= h minimal changes.=0A= >=0A= > When you say "RFC4103 method", do you refer the method where the pri= mary 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.=0A= >=0A= > Regards,=0A= >=0A= > Christer=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: Roni Even (A) [roni.even@huawei.com]=0A= > Sent: 16 October 2019 14:42=0A= > To: James Sandford; Adam Roach; The IESG=0A= > Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.or= g; avt@ietf..org=0A= > Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml= -03: (with DISCUSS and COMMENT)=0A= >=0A= > Hi James,=0A= > RTCP is mandatory for RTP, in the case of packet loss how will y= ou ask for retransmission since RTP is unidirectional. I did not see that = RFC4396 mention uni-directional re-transmission.=0A= > If you are not using retransmission, packet loss will require FE= C or redundancy , so you will need to specify how to use them.=0A= > For redundancy look at RFC4103 for addressing the sequence numbe= r and RFC2198=0A= >=0A= > Roni Even=0A= >=0A= > -----Original Message-----=0A= > From: James Sandford [mailto:james.sandford@bbc.co.uk]=0A= > Sent: Wednesday, October 16, 2019 4:23 PM=0A= > To: Roni Even (A); Adam Roach; The IESG=0A= > Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.or= g; avt@ietf..org=0A= > Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml= -03: (with DISCUSS and COMMENT)=0A= >=0A= > Doesn't RFC4588 require RTCP? That might be a bit over the top f= or a minimal implementation. RFC 4396 references RFC4588 (all be it in a dr= aft state) while also providing a basic uni-directional re-transmission sch= eme as the default.=0A= >=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= > James Sandford=0A= > R&D Project Engineer=0A= >=0A= > BBC Research and Development=0A= > 5th Floor=0A= > Dock House=0A= > MediaCityUK=0A= > Salford=0A= > M50 2LH=0A= >=0A= > Tel: 030304 (09549)=0A= > Web: http://www.bbc.co.uk/rd=0A= >=0A= > ________________________________________=0A= > From: Roni Even (A) [roni.even@huawei.com]=0A= > Sent: 16 October 2019 14:18=0A= > To: James Sandford; Adam Roach; The IESG=0A= > Cc: draft-ietf-payload-rtp-ttml@ietf.org; avtcore-chairs@ietf.or= g; avt@ietf..org=0A= > Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml= -03: (with DISCUSS and COMMENT)=0A= >=0A= > Hi James,=0A= > About packet loss, If the intention is to use retransmission loo= k at RFC4588, it encapsulate the original RTP so no need for changes in ttm= l. You just need to signal support in the SDP.=0A= >=0A= > Roni Even=0A= >=0A= > -----Original Message-----=0A= > From: James Sandford [mailto:james.sandford@bbc.co.uk]=0A= > Sent: Wednesday, October 16, 2019 3:45 PM=0A= > To: Adam Roach; The IESG=0A= > Cc: draft-ietf-payload-rtp-ttml@ietf.org; Roni Even (A); avtcore= -chairs@ietf.org; avt@ietf.org=0A= > Subject: RE: Adam Roach's Discuss on draft-ietf-payload-rtp-ttml= -03: (with DISCUSS and COMMENT)=0A= >=0A= > Responses in-line.=0A= >=0A= > Regards,=0A= > James=0A= >=0A= > >---------------------------------------------------------------= -------=0A= > >DISCUSS:=0A= > >---------------------------------------------------------------= -------=0A= > >=0A= > >Thanks for the work everyone put into this document. I think it= 's not=0A= > >quite ready to publish, due to one ambiguity, one critical miss= ing=0A= > >feature, and the lack of guidance around fragmentation. I also = have two=0A= > >comments that I consider very important, although they don't qu= ite rise=0A= > >to the level of blocking publication.=0A= > >=0A= > >As always, it's possible that my DISCUSS points are off-base, a= nd I'd=0A= > >be happy to be corrected if I've misunderstood anything here.= =0A= > >=0A= > >---------------------------------------------------------------= --------=0A= > >----=0A= > >=0A= > >=A74.1:=0A= > >=0A= > >=0A= > >> When the document spans more=0A= > >> than one RTP packet, the entire document is obtained by= =0A= > >> concatenating User Data Words from each contributing pack= et in=0A= > >> ascending order of Sequence Number.=0A= > >=0A= > >This is underspecified, in that it doesn't make it clear whethe= r it=0A= > >would be valid to split a single UTF-8 or UTF-16 character betw= een RTP=0A= > >packets, and it is nearly certain that different implementation= s will=0A= > >make different assumptions on this point, leading to interop fa= ilures.=0A= > >For example, the UTF-8 encoding of '=A2' is 0xC2 0xA2. Would it= be valid=0A= > >to place the "0xC2" in one packet and the "0xA2" in a subsequen= t packet?=0A= > >=0A= > >Without specifying this, it is quite likely that some implement= ations=0A= > >will use, e.g., UTF-8 strings to accumulate the contents of RTP= =0A= > >packets; and most such libraries will emit errors or exhibit un= expected=0A= > >behavior if units of less than a character are added at any tim= e. (The=0A= > >same point holds for splitting a UTF-16 byte across packets).= =0A= > >=0A= > >I don't think it much matters which choice you make (explicitly= =0A= > >allowing or explicitly forbidding splitting characters between= =0A= > >packets), but it does need to be explicit. I have a slight pers= onal=0A= > >preference for requiring that characters cannot be split (both = for ease=0A= > >of implementation on the receiving end and to more smoothly han= dle=0A= > >missing data due to extended packet loss), but leave it to the = authors and working group to decide.=0A= >=0A= > Thanks for highlighting this. I also have a slight preference fo= r not splitting characters.=0A= >=0A= > >---------------------------------------------------------------= --------=0A= > >----=0A= > >=0A= > >Unlike other definitions to convey non-loss-resilient data on R= TP=0A= > >streams, this document had no defined mechanism to deal with pa= cket=0A= > >loss. This makes it unusable on the public Internet, where pack= et loss=0A= > >is an inevitable feature of the network. The existing text-in-R= TP=0A= > >specifications define procedures to deal with such loss (see, e= .g., RFC 4103 section 4 and RFC 4396 section 5).=0A= >=0A= > I think RFC 4396 Section 5 could be adapted for our purposes. Th= e main issue is the TTML payload document currently makes use of the Sequen= ce Number to identify the order of document fragments. A re-transmitted fra= gment would have a different Sequence Number so there would be no way to ma= tch equivalent packets. A potential solution is to use the 16 Reserved bits= for a new counter that performs the task of identifying fragment order.=0A= >=0A= > How would this affect the progress of this document? While it re= presents a major change to the layout of the payload, the mechanisms used w= ill be identical.=0A= >=0A= > >---------------------------------------------------------------= --------=0A= > >----=0A= > >=0A= > >This format is rather unique in that it, alone among all other = RTP text=0A= > >formats, is designed to send monolithic documents that may stre= tch into=0A= > >the multiple kilobyte range. While fragmentation is mentioned = as a=0A= > >possibility, the document provides no implementation guidance a= bout=0A= > >when to fragment documents, and what sizes each fragment should= assume.=0A= > >RFC 4396 section 4.4 is an example of the kind of information I= would=0A= > >expect to see in a document like this, with emphasis on the fac= t that=0A= > >TTML documents are going to frequently exceed the PTMU for a ty= pical network connection.=0A= >=0A= > I would not be opposed to an equivalent section to this. I'll wo= rk on adapting the referenced section.=0A= >=0A= > >---------------------------------------------------------------= -------=0A= > >COMMENT:=0A= > >---------------------------------------------------------------= -------=0A= > >=0A= > >=A71:=0A= > >=0A= > >> TTML (Timed Text Markup Language)[TTML2] is a media type for= =0A= > >> describing timed text such as closed captions (also known as= =0A= > >> subtitles) in television workflows or broadcasts as XML.=0A= > >=0A= > >Although superficially similar, there are important distinction= s=0A= > >between subtitles (intended to help a hearing audience exclusiv= ely with=0A= > >spoken dialog, typically because the audio is in a different la= nguage=0A= > >or otherwise difficult to=0A= > >understand) and closed captions (intended to aid deaf or=0A= > >hard-of-hearing viewers by providing a direct, word-for-word=0A= > >transcription of dialog as well as descriptions of all other au= dio=0A= > >present). Calling one "also known as" the other is incorrect.= =0A= > >=0A= > >I suggest rephrasing as:=0A= > >=0A= > > TTML (Timed Text Markup Language)[TTML2] is a media type for= =0A= > > describing timed text such as closed captions and subtitles= =0A= > > in television workflows or broadcasts as XML.=0A= >=0A= > 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 t= o support unintelligible speech, and subtitles for the deaf and hard of hea= ring. That said, I have no objection to the alternative wording.=0A= >=0A= > >---------------------------------------------------------------= --------=0A= > >----=0A= > >=0A= > >=A74.2.1.1:=0A= > >=0A= > >> The TTML document instance MUST use the "media" value of the= =0A= > >> "ttp:timeBase" parameter attribute on the root element.=0A= > >=0A= > >This statement makes an assumption that the=0A= > >"http://www.w3.org/ns/ttml#parameter" namespace MUST be mapped = to the "ttp"=0A= > >prefix, which is both bad form and probably not what is intende= d. I=0A= > >suggest rephrasing as:=0A= > >=0A= > > The TTML document instance MUST include a "timeBase" element= from=0A= > > the "http://www.w3.org/ns/ttml#parameter" namespace containi= ng=0A= > > the value "media".=0A= >=0A= > I have spoken to Nigel Megitt (chair of the W3C Timed Text Worki= ng Group) about this. He noted that "timeBase" is an attribute not an eleme= nt. The following alternative is verbose but unambiguous:=0A= >=0A= > 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 "medi= a".=0A= >=0A= > _______________________________________________=0A= > Audio/Video Transport Core Maintenance=0A= > avt@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/avt=0A= >=0A= >=0A= >=0A= >=0A= =0A=