- From: David (Standards) Singer <singer@apple.com>
- Date: Fri, 10 Oct 2014 14:56:43 -0700
- To: Michael Dolan <mdolan@newtbt.com>
- Cc: Timed Text Working Group <public-tt@w3.org>
On Oct 10, 2014, at 11:04 , Michael Dolan <mdolan@newtbt.com> wrote: > 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. yes > > -----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. > > David Singer Manager, Software Standards, Apple Inc.
Received on Friday, 10 October 2014 21:57:12 UTC