- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 7 May 2014 12:59:01 +0000
- To: Michael Dolan <mdolan@newtbt.com>, "public-tt@w3.org" <public-tt@w3.org>
Assuming you mean that we cover this in our regular weekly telcon on 15th
May, I'm happy to include it on the agenda.
It might be helpful if you could point us in the general direction of
where these misunderstandings are - from my recollection so far on this
thread we've covered:
1. using {profile} vs {namespace, schemaLocation},
2. processor behaviour vs declaration of document conformance, aka
semantics
3. syntax of the string formed by combining short labels,
4. [mis]use of the @codecs parameter when @profiles or simply additions to
the mime type would be better
5. registration process of short labels in W3C
6. amendments needed in external documents e.g. RFC 6381, IANA
application/ttml+xml registration
Is it possible to locate the misunderstandings in any of these categories?
Nigel
On 07/05/2014 12:30, "Michael Dolan" <mdolan@newtbt.com> wrote:
>There are misunderstandings here that we don't seem to get past. I think
>we need to discuss in a meeting. I am unable to attend this week's
>telecon, so perhaps let's shoot for the 16th.
>
>-----Original Message-----
>From: David Singer [mailto:singer@apple.com]
>Sent: Tuesday, May 06, 2014 4:35 PM
>To: Nigel Megitt
>Cc: Michael Dolan; public-tt@w3.org
>Subject: Re: Liaison response - template on MIME type parameter for
>TimedText
>
>
>On May 6, 2014, at 8:29 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>
>> On 06/05/2014 16:08, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>
>>> I'm still not sure we're in agreement on what can be registered and
>>> signaled. I maintain that any foreign namespace extensions must be
>>> permitted to be registered, not just "flavors" (profiles) of TTML.
>>> It's not about whether W3C defined the profile or not. It's about
>>> including registration and use of extensions.
>>>
>>> Before we deal with versions of profiles and the other semantics, can
>>> we get closure on the above?
>>
>> Okay let's try to do that.
>>
>> I'm not persuaded that namespaces are at the heart of this.
>
>Nor me. I think that this is a question for the profiles themselves.
>“In this profile, only namespaces X, Y and Z may be present”. “In this
>profile, the basic structures must be from namespace X, but any extension
>elements and attributes from other namespaces are permitted, though a
>reader can ignore them.” and so on.
>
>>
>> Profiles of TTML are languages based on TTML which can be expected in
>> general to contain:
>>
>> . A constrained subset of a version of TTML, where the constraint may
>> be in syntax or semantics, such as restricting the color space etc.
>> . Behaviours not specified by TTML, such as defining for a specific
>> scenario initial values left absent from the more general TTML.
>> . Extensions relative to TTML, which may be new syntax and semantics
>> that by definition must be in alternate namespaces.
>>
>> (I deliberately omit misuse of existing TTML vocabulary in ways not
>> permitted in TTML)
>>
>> Namespaces are therefore a subset of what a receiving processor might
>> need to address, and can be derived from knowledge of the registered
>> short name or, if the processor chooses to parse the document, by
>> inspecting the document itself.
>>
>> Maybe I've misunderstood the problem?
>
>I think you have it. Profiles are about interop, and namespaces and
>schemas are only a part of that. Behavior is important (just like in WGs
>:-))
>
>>
>> Nigel
>>
>>
>>
>>>
>>> Mike
>>>
>>> -----Original Message-----
>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>> Sent: Tuesday, May 06, 2014 7:39 AM
>>> To: Michael Dolan; public-tt@w3.org
>>> Subject: Re: Liaison response - template on MIME type parameter for
>>> TimedText
>>>
>>> On 06/05/2014 13:22, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>>
>>>> Nigel-
>>>>
>>>> I am not promoting namespace/schema over our agreed design approach
>>>> of the other day using profile strings, etc.
>>>
>>> Glad we're agreed!
>>>
>>>>
>>>> However, I have to say that in #1, well, don't do that. If it
>>>> matters, provide a different schema URI and call it something other
>>>>than "ttml"
>>>> (e.g. "imsc"). For #2, OK but those are basically the same
>>>> unanswered questions as for the profile design.
>>>
>>> It seems to be considered good practice [2] to have mutable
>>> namespaces as long as they're declared as such, which is the case in
>>> TTML1. The specification versioning problem is unlikely to disappear,
>>> and requiring a change of namespace name for every new version of the
>>> same specification would probably cause more problems than it would
>>>solve.
>>>
>>> [2] http://www.w3.org/2001/tag/doc/namespaceState.html#namespacedef
>>>
>>>> I believe that we must be able to signal capabilities other than one
>>>> or more TTML profiles, e.g. "TTML" + required 3rd party namespace,
>>>> or the design will be mostly useless in my opinion. Constraining
>>>> it to one or more pure profiles of TTML will have limited
>>>> application. We need to resolve this before attempting semantic
>>>> discussions about a constrained design.
>>>
>>> Again, agreed, though I'd make this more a logical concept than
>>> relating it to namespaces. The proposal on the table would permit
>>> other flavours of TTML than those published/recommended by W3C to be
>>> registered. I would propose that the decision "is this a flavour of
>>> TTML that we should register?" can be delegated to the TTWG and the
>>> W3C consensus process, after bringing a "request to register" to the
>>> group. Listing a format on a W3C registry page would merely log the
>>> usage of the short name and would not confer any stronger form of
>>> validation or endorsement of the listed format. I'd expect the group
>>> to reject any formats that do not appear to be a form of TTML at all.
>>>
>>> Take for example EBU-TT-D: it uses a subset of TTML namespace
>>> features and additional EBU namespace features, and a fully
>>> conformant processor for this type should process both sets. However
>>> I wouldn't describe those namespaces in the short codes or the
>>> registry - I'd just say the equivalent of "this is TTML and this is
>>> EBU-TT-D" and leave the namespace issue to the receiving system. If
>>> it knows it can process EBU-TT-D then it must know about the EBU
>>> namespace already. If it is unaware of EBU-TT-D then it may choose to
>>> process as TTML and would in that case use the TTML rules and
>>>effectively discard the non-TTML namespace content.
>>>
>>> Does this come down to a semantic question for the processor of
>>> 'processor must understand format Z' vs 'be warned that this document
>>> may contain features from format Z'? I don't wish to redefine what's
>>> already in TTML1SE and planned for TTML2 during parsing but we need
>>> to guide a pre-parsing decision with this information. Maybe we need
>>> a second operator additional to + that means 'and the processor must
>>> be able to process it', such as & (assuming that's a legal character
>>> in the codecs parameter).
>>>
>>> So:
>>>
>>> codecs = stpp.TTML.tt1f+ebuttd would tell the receiving system that
>>> it may encounter EBU-TT-D content, whereas
>>>
>>> codecs = stpp.TTML.tt1f&ebuttd would tell the receiving system that
>>> it must be able to process EBU-TT-D content.
>>>
>>> In both cases the string after TTML begins with at least one TTML
>>>profile.
>>> I'm not sure if that would always be possible.
>>>
>>>
>>> Or maybe we don't need to do anything other than describe the
>>> contents and leave the rest up to the receiving system.
>>>
>>> Kind regards,
>>>
>>> Nigel
>>>
>>>>
>>>> Regards,
>>>>
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>> Sent: Tuesday, May 06, 2014 2:55 AM
>>>> To: Michael Dolan; public-tt@w3.org
>>>> Subject: Re: Liaison response - template on MIME type parameter for
>>>> TimedText
>>>>
>>>> There's a more substantive issue IMHO. Namespace and schemaLocation
>>>> do not adequately identify a particular variant of TTML, nor is it
>>>> clear how they should be derived. There are two issues, at least:
>>>>
>>>> 1. If a profile uses a mutable namespace (which I would normally
>>>> expect) then different versions of the same profile will have the
>>>> same namespace and schemaLocation and thus not be distinguishable.
>>>> 2. It is unclear whether all of the namespaces used in a document
>>>> must be listed or just those that are relevant for downstream
>>>> processing. If a processor sees a namespace that was not listed what
>>>> should it's behaviour be? I do not believe that we are trying to
>>>> create something here that should have an impact during processing
>>>> of the document; rather the parameter can be used either to select
>>>> an appropriate document or to decide whether or not to download and
>>>> process a document or ignore it.
>>>> Similarly it should not be a requirement for the MP4 packager to
>>>> parse the document to work out all of the namespaces that are
>>>>actually used.
>>>>
>>>> Returning to the current alternative proposal, I have a question
>>>> about the stpp.TTML.[short name1]+[short name 2]+[etc] idea: what is
>>>> the order of precedence if we use the + symbol?
>>>>
>>>> I can imagine stpp.TTML.DFXP+IMSC being interpreted either as "this
>>>> document is a DFXP TTML document and an IMSC TTML document" or "this
>>>> document is a DFXP TTML document and some other unregistered thing
>>>> called IMSC". Are we free to say that the + operator has higher
>>>> precedence than the . "operator" to ensure that the former
>>>> interpretation holds?
>>>>
>>>> This isn't as obvious as it looks at first: in TTML §4 [1] we say
>>>> abstract document types can be validated by pruning all content in
>>>> non-TT namespaces. Consider an alternate format XX that has a
>>>> similar rule that prunes all non-XX namespace content. Someone
>>>> constructs a document that contains both TT namespace elements and
>>>> XX namespace elements at the top level. The document now serves dual
>>>> purposes (ignoring for the moment whether or not this is a good
>>>> idea), and could potentially be described either as
>>>> "stpp.TTML.tt1f+stpp.XX" or as "stpp.TTML.tt1f+XX" - which of these
>>>> is correct depends on how we and MPEG collectively define the syntax
>>>>in the codecs parameter.
>>>>
>>>> [1] http://www.w3.org/TR/ttml1/#profiles
>>>>
>>>> In the current proposal there is no way to signal conformance to two
>>>> mutually independent XML formats that can legally be combined in the
>>>> same document.
>>>>
>>>> (in case you're wondering, no, I don't actually want to do this but
>>>> I'm just observing the effect of the undefined parts of the current
>>>> proposal)
>>>>
>>>> Nigel
>>>>
>>>>
>>>> On 05/05/2014 14:58, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>>>
>>>>> Cyril-
>>>>>
>>>>> No one (I don't think) is opposed to addressing the issue. And, I
>>>>> think W3C has accepted the ownership of its parts of it. The
>>>>> questions are about the technical details.
>>>>>
>>>>> There already is a registered media type - "application/ttml-xml".
>>>>> So, one of my questions was essentially why not build on that?
>>>>> Dave seems to prefer building on the MP4 4C code and I'm still
>>>>> studying the two approaches.
>>>>>
>>>>> As you know, the namespaces and schemaLocations are already
>>>>> signaling at the
>>>>> MP4 layer. They can be extracted into a codecs string, but there
>>>>> are apparently objections to the resulting length of the string. I
>>>>> thought that was the only real issue being addressed, no?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>>>>> Sent: Monday, May 05, 2014 4:43 AM
>>>>> To: public-tt@w3.org
>>>>> Subject: Re: Liaison response - template on MIME type parameter for
>>>>> TimedText
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Some points worth highlighting/repeating:
>>>>>
>>>>> - Aside from the MP4 problem, the problem is general. Consider a
>>>>> DASH MPD pointing to a TTML file (not packaged in a MP4). How can a
>>>>> player know that it'll be able to play it meaningfully without
>>>>> downloading the entire TTML file? Does it actually need to know or
>>>>> will it always be able to do something with a TTML file? The
>>>>> solution to this problem will provide the basis for the solution to
>>>>> the MP4 problem. Has the TTML WG considered defining a 'codecs' or
>>>>> 'profile' MIME parameter for TTML?
>>>>>
>>>>> - the codecs parameter of MP4 files is useful for identifying the
>>>>> content of each track in the file before the file is fully
>>>>>downloaded.
>>>>> In Adaptive Streaming contexts such as DASH, the initialization
>>>>> segment can also be downloaded in a first step to get information.
>>>>> So the codecs parameter does not have to provide all information.
>>>>> It could just indicate that the track contains some flavor of TTML
>>>>> and let the initialization segment provide more details. In that
>>>>> case, the solution could be as simple
>>>>> as: codecs="stpp.ttml"
>>>>>
>>>>> - If more than TTML is needed, remember that a typical workflow for
>>>>> packaging/dashing is: get one (or more) TTML file, package it into
>>>>> an
>>>>> (existing) MP4 file, produce an MPD from that MP4 file. Only in the
>>>>> last step is the 'codecs' parameter generated. In MSE cases, you
>>>>> don't even need the MPD but you need to get (most likely in JS) the
>>>>> codecs parameter to create the source buffer. Ideally, the TTML
>>>>>'codecs'
>>>>> string generator should not have to look at the content of the TTML
>>>>> document, only at the track sample entry (similar to AVC codecs
>>>>> generation).
>>>>>
>>>>> Regards,
>>>>> Cyril
>>>>>
>>>>> 03/05/2014 20:01, David Singer a écrit :
>>>>>> On May 3, 2014, at 9:06 , Glenn Adams <glenn@skynav.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Fri, May 2, 2014 at 12:23 PM, David Singer <singer@apple.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Apr 30, 2014, at 16:40 , Michael Dolan <mdolan@newtbt.com>
>>>>>>>wrote:
>>>>>>>
>>>>>>>> Nigel, Dave and all-
>>>>>>>>
>>>>>>>> Is there a TTWG Proposal?
>>>>>>>>
>>>>>>>> Would ³stpp² be registered somewhere where it would be
>>>>>>>> unambiguous from
>>>>> other Codecs strings unrelated to TTML? I don¹t mean the sample
>>>>> entry 4C code, but in the Codecs string namespace. Wouldn¹t it
>>>>> have to be ³application/mp4+stppŠ.²? Or why not use
>>>>> ³application/ttml+xml² (and similar for WebVTT)?
>>>>>>> The codecs string starts with the 4CC of the sample entry. After
>>>>>>> that,
>>>>> whoever defined that 4CC gets to say what¹s the next element. And
>>>>> they get to say what¹s after that, and so on.
>>>>>>>
>>>>>>> stpp says ³some sort of XML²,
>>>>>>>
>>>>>>> since VTT isn't XML, then would it use something different from
>>>>>>>stpp?
>>>>>> yes, we have different 4CCs for text-based and XML-based formats.
>>>>>> stpp is for XML-based
>>>>>>
>>>>>>>
>>>>>>> and is owned by MPEG. So indeed the step that goes from Œstpp¹
>>>>>>> to Œsome
>>>>> sort of TTML¹ is owned by MPEG, and MPEG still needs to resolve this.
>>>>>>>
>>>>>>> The thrust is that IF MPEG solves that, THEN there will be names
>>>>>>> to identify TTML dialects, that could go next. So you would see
>>>>>>>
>>>>>>> codecs=stpp.<some MPEG magic to say it is TTML
>>>>>>> happens>.TTMLFULL+IMSC+SDPUS+EBUTT
>>>>>>>
>>>>>>> I would expect something more simple, e.g.
>>>>>>>
>>>>>>> stpp.vtt
>>>>>>> stpp.ttml.tt1f
>>>>>>> stpp.ttml.tt1p
>>>>>>> stpp.ttml.tt1t
>>>>>>> stpp.ttml.sdpu
>>>>>>> stpp.ttml.st10
>>>>>>> stpp.ttml.st13
>>>>>> indeed, MPEG is likely to say that TTML means ³go to the W3C, thou
>>>>> sluggard, and be wise²
>>>>>>
>>>>>>> where we have a registry for mapping the third IDs above to TTML
>>>>>>> profile
>>>>> designators, e.g.
>>>>>>>
>>>>>>> tt1f -> http://www.w3.org/ns/ttml/dfxp-full
>>>>>>> tt1p -> http://www.w3.org/ns/ttml/dfxp-presentation
>>>>>>> tt1t -> http://www.w3.org/ns/ttml/dfxp-transformation
>>>>>>> tt1u -> http://www.w3.org/ns/ttml/sdp-us s10f ->
>>>>>>> http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-ful
>>>>>>> l
>>>>>>> s13f ->
>>>>>>> http://www.smpte-ra.org/schemas/2052-1/2013/profiles/smpte-tt-ful
>>>>>>> l
>>>>>>>
>>>>>>> we definitely do not want to create a new syntax/language for use
>>>>>>> in codecs that describes some way to combine profiles; that
>>>>>>> function is already defined by the ttml profile definition
>>>>>>> document syntax
>>>>>> we¹re not, but we have to indicate somehow that a document is
>>>>>> compatible
>>>>> with more than one profile. we also are not restricted here to a
>>>>> 4-character-name, so we can use slightly longer names if they are
>>>>> mnemonic.
>>>>>>
>>>>>> we can¹t split into several entries as you suggest; there is one
>>>>>> entry
>>>>> per track, those separated by commas.
>>>>>>
>>>>>> codecs=stpp.ttml.tt1f,stpp.ttml.tt1p
>>>>>>
>>>>>> means two tracks, whereas
>>>>>>
>>>>>> codecs=stpp.ttml.tt1f+tt1p
>>>>>>
>>>>>> means one track compatible with two TTML profiles. Big difference.
>>>>>> (I am not wedded to plus, but comma and period are both taken
>>>>>> already)
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> for example.
>>>>>>>
>>>>>>> For the TTWG to say ³yes, we¹ll take on dialect naming and
>>>>>>> forming that
>>>>> second-level parameter² is important; it then means that if MPEG
>>>>> finds a clean solution to the first level, the actual problem in
>>>>> hand is solved.
>>>>> I¹d like the MP4 people to realize before the July meeting that
>>>>> this is urgent, and come up with ideas and maybe online discussion
>>>>>ASAP.
>>>>>>>
>>>>>>> This is all provisional ‹ on the TTWG getting agreement not only
>>>>> internally, but with the partners; and on us all liking the final
>>>>> result, of course.
>>>>>>>
>>>>>>> Makes sense?
>>>>>>>
>>>>>>>> I understand how one could signal profiles of TTML that a
>>>>>>>> document
>>>>> conformed to concurrently, as in the example all of TTML and
>>>>>EBU-TT.
>>>>> But
>>>>> the signaling requirements go beyond that there is often multiple
>>>>> namespaces in use in one document that are not, as an aggregate, a
>>>>> single ³profile². So, these must be explicitly signaled as well
>>>>> since nearly all profiles permit foreign namespaces. To
>>>>> accommodate this, the ³short names² have to be defined as ³profiles
>>>>> of namespaces² I think.
>>>>>>>>
>>>>>>>> For example, if a document uses the CFF-TT text profile of the
>>>>>>>> TTML Full
>>>>> profile, plus SMPTE-TT #608 (US captions), plus CFF-TT metadata,
>>>>> and it was compatible with IMSC, SDP-US and EBU-TT, then it might
>>>>>look like:
>>>>> Codecs=xxxxx.TTMLFULL+IMSC+SDPUS+EBUTT+CFFT+CFFM+SMPTE608.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> p.s. I would give the SC29 Secretary a hint about the target of
>>>>>>>> the
>>>>> liaison (MPEG v JPEG). And, you understand you will not receive a
>>>>> reply until mid-to-late July, right?
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>>>> Sent: Wednesday, April 30, 2014 11:48 AM
>>>>>>>> To: watanabe@itscj.ipsj.or.jp
>>>>>>>> Cc: Timed Text Working Group
>>>>>>>> Subject: Liaison response - template on MIME type parameter for
>>>>>>>> TimedText
>>>>>>>>
>>>>>>>> Dear Mr. Watanabe,
>>>>>>>>
>>>>>>>> Thank you for your liaison N14444 of April 2014.
>>>>>>>>
>>>>>>>> We think that we can indeed find a solution together. We are
>>>>>>>> looking into creating a table of formal "short names" for the
>>>>>>>> profiles of W3C TTML and the profiles of formats derived from it
>>>>>>>> (such
>>>>> as SMPTE-TT, EBU-TT, and so on). If MPEG were to propose how to
>>>>> step from the four-character-code of the sample entry
>>>>> (XMLSubtitleSampleEntry and
>>>>> XMLMetaDataSampleEntry) to something that identifies "a document
>>>>> compatible with one or more profiles of TTML", then we could
>>>>> propose a string composed of a set of one or more these short names
>>>>> as the next parameter.
>>>>>>>>
>>>>>>>> For example, say W3C defines two profile short names "W3CTTML"
>>>>>>>> and "EBUTTML", and MPEG defines the name "TTML" as referring to
>>>>>>>> the overall family, one might see
>>>>>>>>
>>>>>>>> codecs=stpp.TTML.W3CTTML+EBUTTML,avc1
>>>>>>>>
>>>>>>>> as a codecs string of a file carrying AVC (H.264) and TTML
>>>>>>>> subtitles that are additionally EBU-TT conformant.
>>>>>>>>
>>>>>>>> We would check with those deriving from TTML (e.g. at SMPTE, EBU
>>>>>>>> and
>>>>> DECE) if this approach and design are acceptable, before we
>>>>> formalise this.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>> Nigel Megitt, David Singer (chairs, Timed Text Working Group,
>>>>>>>> W3C)
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Nigel Megitt
>>>>>>>> Lead Technologist, BBC Technology, Distribution & Archives
>>>>>>>> Telephone: +44 (0)3030807996
>>>>>>>> Internal (Lync): 0807996
>>>>>>>> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London
>>>>>>>> W12 7TP
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> ---------------------
>>>>>>>>
>>>>>>> David Singer
>>>>>>> Manager, Software Standards, Apple Inc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> David Singer
>>>>>> Manager, Software Standards, Apple Inc.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cyril Concolato
>>>>> Multimedia Group / Telecom ParisTech
>>>>> http://concolato.wp.mines-telecom.fr/
>>>>> @cconcolato
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -----------------------------
>>>> 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.
>>> -----------------------------
>>>
>>>
>>
>>
>>
>> -----------------------------
>> 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.
>> -----------------------------
>
>David Singer
>Manager, Software Standards, Apple Inc.
>
>
>
-----------------------------
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.
-----------------------------
Received on Wednesday, 7 May 2014 12:59:34 UTC