Re: [payload] new draft - RTP Payload for TTML Timed Text

["Roni Even (A)" <[e-mail]>]

Hi James,
Please change the individual draft.  It will be good to get agreement from Nigel or others from 3GPP based on these changes before progressing the work in the IETF

Regards
Roni Even
Payload WG co-chair

From: James Sandford [mailto:[e-mail]]
Sent: Wednesday, February 13, 2019 11:25 AM
To: Roni Even (A); Nigel Megitt; [e-mail]
Subject: RE: [payload] new draft - RTP Payload for TTML Timed Text

Thanks, Roni. Should I make these changes now or wait until the call for the WG to adopt v02 has lapsed?

Regards,
James


==========
James Sandford
R&D 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) [[e-mail]]
Sent: 12 February 2019 07:52
To: Nigel Megitt; [e-mail]<mailto:[e-mail]>
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text
Hi,
Thanks for the information.
The way I see it is that this document only wants to specify how to send TTM time text using RTP which is not specified by W3C

I think that the text explains it but maybe we need better clarification, any input is welcome. I think that at least it should say that this document only define how to carry TTML time text over RTP using the media subtype defined by W3C and reference the relevant W3C document.

I agree that we do not need the registration template since the document suggest using the current registration in the IANA media  type, so the IANA consideration should only ask for adding the reference to this document in the current registration. This assumes that there are no changes in the registration required.   Another direction is to have a different media subtype name for the RTP usage but In see no real reason if the document only specify how to use this payload over RTP and change nothing in the current registration.

The only other comment I noticed is “A request to make sure that the language about profile signalling does not imply that the codecs parameter can denote all profiles, especially in the case that the payload document contains an embedded profile.“  This should be addressed by the authors

Let the WG know if this sounds reasonable
Roni Even
Payload WG co-chair




From: payload [mailto:[e-mail]] On Behalf Of Nigel Megitt
Sent: Monday, February 11, 2019 5:16 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text

Dear IETF Payload group,

This draft was discussed by the W3C Timed Text Working Group (TTWG) on 2019-02-07 [1].

[1] Minutes of W3C TTWG meeting 2019-02-07: https://www.w3.org/2019/02/07-tt-minutes.html#item03

During the meeting concern was raised about the approach to the IANA registered media type, specifically the meaning of section 8. IANA Considerations.

There was consensus amongst the group that the text specifying that this text:

“The media types registry SHOULD be updated to make reference to this document for the application/ttml+xml media type.”

is incorrect and needs to be changed. The media type registration for TTML is owned by W3C and should not be changed by IETF – we note that the change control is clearly marked as being owned by W3C so in that sense this text is inconsistent.

The IANA media type registration itself defers to the TTWG document “TTML Media Type Definition and Profile Registry” [2] which is already referenced by the RTP Payload draft. An improvement would therefore be to update the text in section 8 to suggest that [2] can be updated to include the profiles defined within the payload document. Indeed doing so would result in the creation of a short code for the profile processor mentioned in section 4.2.1.2.1.3 Processor profile signalling.

[2] TTML Media Type Definition and Profile Registry https://www.w3.org/TR/ttml-profile-registry/


The TTWG also discussed two additional concerns without closing on a position at this time:

  1.  A query whether the media type registration information really needs to be copied in at all here or if it can be referenced;
  2.  A request to make sure that the language about profile signalling does not imply that the codecs parameter can denote all profiles, especially in the case that the payload document contains an embedded profile.
TTWG may provide further input on those two points but would welcome further input especially on the first.

Kind regards,

Nigel Megitt as Chair of W3C TTWG




----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------



----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------