RE: {minutes} TTWG Meeting 2015-10-01

I’m OK with including the combination details as long as the extra substantive material does not affect the Note publication process.

 

For stpp, I believe the text is currently clear that we are not defining profiles (we don‘t define any profiles in this).  At this point I think I need proposed text to address this without forbidding its use in the codecs parameter.  For example, would it help to say, “If the profile is unknown, ‘stpp’ may be used.”?

 

Cyril, do we need to take this up in ISO in 2 weeks?

 

                Mike

 

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Sent: Friday, October 2, 2015 8:30 AM
To: Michael Dolan <mdolan@newtbt.com>; 'Glenn Adams' <glenn@skynav.com>; 'Cyril Concolato' <cyril.concolato@telecom-paristech.fr>
Cc: 'TTWG' <public-tt@w3.org>
Subject: Re: {minutes} TTWG Meeting 2015-10-01

 

From: Michael Dolan < <mailto:mdolan@newtbt.com> mdolan@newtbt.com> Date: Friday, 2 October 2015 16:24

 

I made the wiki draft non-normative (I believe) by removing the combination language.  

 

I understood our plan was to concurrently document the media extension in this Note and in TTML2 (which would extend it). The revision to the media type is to add an optional “codec” parameter with a syntax of the form: codec=<short_name>[<extension_syntax>], where:

 

short_name shall be from the Profile Registry

extension_syntax is an optional string to be defined by TTML2 for the combination syntax and semantics previously in the CodecsProfile wiki.

 

The latter is an attempt to give near term users a heads up that there may be characters following the short_name in the future and thus not to do a string compare on the entire value.

 

I would be in favour of including the proposal for the extension syntax now because it has a clear use case and I don't expect us to need to change it. That's an even clearer heads up!

 

The delay to Rec publication for this registry will kill anyone using it in my view.  It will eventually all be in Rec TTML2 for those that can’t handle a Note for some reason (although I agree with Glenn that “normative” is in the eye of the one citing it and it really should not be an issue). DASH-IF IOP 3.1 already cites the wiki, so we need to do this ASAP!

 

>> b) the registry does not confuse people by redefining what MPEG defines

>>  b) is partially addressed as the 'stpp' row is still there.

 

Summarizing the last email on this – it is there because it is in use today, for better or worse.  Some options: 1) delete it and thus make existing use illegal; or 2) allow it but clearly deprecate its use.

 

I may have misunderstood the issue with stpp but I thought that it can be used for TTML since TTML is an XML subtitle format, but what we have to make sure we don't do is claim that we are defining it, or somehow duplicate the definition. Rather we have to clarify that we're only defining an extension to allow content providers to specify exactly which profile(s) of TTML a processor needs to support to process the document.

 

 

>> which RFC you are talking about or what you mean by "non-W3C infrastructure issues".

 

RFC 6381 and the general lack of definition of definition/registration for some codec parameter values in use today by MPEG.

 

Regards,

 

                Mike

 

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Sent: Friday, October 2, 2015 7:20 AM
To: Glenn Adams <glenn@skynav.com <mailto:glenn@skynav.com> >; Cyril Concolato <cyril.concolato@telecom-paristech.fr <mailto:cyril.concolato@telecom-paristech.fr> >
Cc: TTWG <public-tt@w3.org <mailto:public-tt@w3.org> >
Subject: Re: {minutes} TTWG Meeting 2015-10-01

 

From: Glenn Adams < <mailto:glenn@skynav.com> glenn@skynav.com> Date: Friday, 2 October 2015 15:10

 

 

On Fri, Oct 2, 2015 at 1:16 AM, Cyril Concolato <cyril.concolato@telecom-paristech.fr <mailto:cyril.concolato@telecom-paristech.fr> > wrote:

Hi all,

Le 01/10/2015 18:40, Nigel Megitt a écrit :

PROPOSAL: Draft a WG Note describing the profile short name
    registry and updating the IANA media registration, based on
    what's in the current profile registry wiki page plus the
    addition of the codec parameter to the existing TTML media type
    registration.

    nigel: Does that address Cyril's concern about using the codec
    profile?

My concerns were that:
a) if the registry is a note, it should not contain normative material

 

whether a publication is used normatively is not a property of the publication, but of the reference to the publication; there have been many W3C Notes published with technical material that have been used normatively by other publications;

 

That's true but maybe the question we should be asking is: does any organisation hoping to use this document have a strong requirement for it to have Recommendation status? And if so, what concern do they believe will be mitigated by that? Our current view is that a Note is fine.

 

 

b) the registry does not confuse people by redefining what MPEG defines
c) the use of the identifier would be beneficial even outside of MPEG files, in particular for plain TTML over HTTP.

a) has been addressed by some clarifications that Mike made.
b) is partially addressed as the 'stpp' row is still there.
c) is addressed by the IANA update.


    mike: Yes, without going into all the details, the RFC is out
    of date, but we can independently
    ... proceed here with tidying up, to resolve any public use or
    adoption. Cyril is concerned
    ... more globally about non-W3C infrastructure issues. We can
    solve ours locally.

I'm not sure what this means, which RFC you are talking about or what you mean by "non-W3C infrastructure issues".

FYI, the next MPEG meeting is at the end of October. Can the Note be published by then? In any case, can I ask that the group makes a liaison to MPEG informing about that Note so that MPEG can decide on using it for defining its codecs parameter?

Cyril


-- 
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/
@cconcolato




 

 

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

http://www. <http://www.bbc.co.uk> 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.

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