RE: MPEG codecs parameter - discussion summary ISSUE-305

I hear "MPEG" (you, Cyril, and maybe me) saying the short name design path
that TTWG is on is good enough, right?  Therefore, I think Q1 is not really
an issue, even though there is not a crisp integer answer.

-----Original Message-----
From: David (Standards) Singer [mailto:singer@apple.com] 
Sent: Friday, October 10, 2014 11:01 AM
To: Michael Dolan
Cc: Timed Text Working Group
Subject: Re: MPEG codecs parameter - discussion summary ISSUE-305

I don't think there is a formal limit on the length of a media type with its
parameters, but common sense should prevail.

On Oct 10, 2014, at 10:39 , Michael Dolan <mdolan@newtbt.com> wrote:

> Thanks, Nigel.
> 
> Some clarifications:
> 
> Regarding item 6, it is not an "extension".  It is a media type parameter.
Today, a fully qualified media type string for TTML is, for example:
> 
> 	"application/ttml-xml;charset=utf-8;profile=
http://www.w3.org/ns/ttml/profile/dfxp-full"
> 
> We're discussing adding/replacing a parameter to support the short name
profile syntax proposed in TTML2 (e.g. Q2 below).
> 
> And, in #7, the media type above is TTWG's decision not MPEG's.  The full
codecs parameter (which will use the media type string) is MPEG's domain.
> 
> #9 and Q1 was a input from MPEG without being very prescriptive, except
that sets of namespace or profile strings is "too long" and sets of short
registry names is "probably short enough". 
> 
> 	Mike
> 
> -----Original Message-----
> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
> Sent: Friday, October 10, 2014 10:22 AM
> To: 'Timed Text Working Group'
> Subject: MPEG codecs parameter - discussion summary ISSUE-305
> 
> All,
> 
> There has been some off-list discussion about our profiles registry and
the MPEG codecs parameter (Issue-305 etc). Below is a summary of where we're
up to - the purpose of sending this to the group is to give the opportunity
for all members to raise any concerns or proposals.
> 
> SUMMARY
> -------
> 
> 1. To be useful, MPEG needs our response by October 19.
> 
> 2. The steps we need to take are:
> a) agree that we will host a registry (done in principle I think, but it
would help to formalise it with a resolution)
> b) propose a format for the codecs parameter
> c) draft a response to MPEG
> 
> 3. The TTML2 processorProfiles and profile designator format will remain
as defined now in the editor's draft.
> 
> 4. We're willing to host a registry of short names for both the standard
designators listed in TTML1 and TTML2 and non-standard external designators,
similar to if not identical to that at [1] - the precise contents of this
registry can be discussed further, for example in the agenda slot we have
set aside at TPAC. This will be external to the TTML2 recommendation.
> 
> 5. The syntax for expressing processor profile combinations using short
names is as described at [1].
> 
> 6. The mechanism for signalling what kind of TTML processor a given
document needs will be included as an extension to the MIME type, i.e.
> "application/ttml+xml;[EXTENSION GOES HERE]".
> 
> 7. The MP4 codecs parameter will include the MIME type including the
extension. (this is MPEG's decision to make not ours)
> 
> 8. We do not intend to create a new MIME type for TTML2 but may revise the
existing MIME type for TTML.
> 
> 9. There is a maximum string length constraint for the MIME type - what is
that maximum though?
> 
> 10. The remaining area of debate is whether to redefine the profile
parameter in the MIME type (current registration is at [2]) or to create
something new, for example "procprofs". If there are no implementations that
use the current profiles addition to the MIME type then it seems most useful
to redefine it to use the short names. Conversely if there's a need to
maintain some form of backwards compatibility for existing implementations,
then we should define a new parameter for processor profiles and deprecate
the existing profiles while defining rules for systems that are interpreting
the type so that they take the most appropriate action.
> 
> 11. When we have concluded on the redefine profile vs define a new thing
point (10 above) we can draft our response to MPEG, and resolve to send it
in our meeting of Thursday 16th October. (I've assumed that we will also
resolve to host the registry page during that meeting)
> 
> OUTSTANDING QUESTIONS
> ---------------------
> 
> Q1. What is the length limit we need to adhere to for the MIME type, and
where does the requirement come from?
> 
> Q2. Should we redefine profile or define a new additional parameter?
> 
> REFERENCES
> ----------
> 
> [1] Codecs registry draft page:
https://www.w3.org/wiki/TTML/CodecsRegistry
> [2] Current TTML IANA registration:
> http://www.iana.org/assignments/media-types/application/ttml+xml
> 
> 
> 
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 10 October 2014 18:05:10 UTC