- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 29 Jan 2016 10:33:16 -0700
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: Dae Kim <dakim@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
- Message-ID: <CACQ=j+dunbMLVtROKUL8ncxC4R1j3NLpyOcM-JciVsZQP0HPdQ@mail.gmail.com>
On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > Hi Glenn, > > > This could also be done in other ways, such as by specifying these > properties on the tt element, > > from which all inheritance would occur (in TTML2); however, that > wouldn't work for properties > > that don't inherit, like tts:showBackground, etc. > > Why doesn't tts:showBackground inherit? > It was originally defined on region in TTML1, which has no way for a region to inherit. However, we are adding root element inheritance in TTML2 (e.g., from tt to head to layout to region). Perhaps we need to review uninheritable properties in TTML2 to determine if we need to upgrade them to inheritable, though doing so will require careful consideration of interoperability with TTML1 behavior. > > Thanks, > > -- Pierre > > On Fri, Jan 29, 2016 at 9:11 AM, Glenn Adams <glenn@skynav.com> wrote: > > I can provide some respond to this. > > > > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux < > pal@sandflow.com> > > wrote: > >> > >> Hi Dae, > >> > >> > initial > >> > >> How does Netflix plan to use <initial>? > > > > > > The TTT tools already support the initial element with the ttml2 model, > and > > has found it to be very useful in specifying a variety of non-default, > > global style settings, such as default color and font related properties, > > etc. > > > > For example, the CAP2TT tool in TTT specifies a test configuration file > that > > specifies a template for generating TTML2 output files in which is > specified > > the following: > > > > <initial tts:fontSize="4vh"/> > > <initial tts:lineHeight="5vh"/> > > <initial tts:showBackground="whenActive"/> > > > > Here, initial is used to alter the default initial value. This could > also be > > done in other ways, such as by specifying these properties on the tt > > element, from which all inheritance would occur (in TTML2); however, that > > wouldn't work for properties that don't inherit, like tts:showBackground, > > etc. > > > > Note that be using initial to specify an explicit tts:lineHeight, then > there > > is no possibility of using the default initial value of 'normal' (which > has > > been a problem with IMSC content). > > > > It is also useful for redefining the default initial value of > > tts:backgroundColor and resolving the platform dependent default initial > > value of tts:color. > > > > > >> > >> > >> The current ED states "conditionalized element" is "To Be Defined". > >> > >> Best, > >> > >> -- Pierre > >> > >> On Thu, Jan 28, 2016 at 9:35 AM, Dae Kim <dakim@netflix.com> wrote: > >> > Hello all, > >> > > >> > We're starting to engage with subtitle program vendors for TTML2 > support > >> > and > >> > I'm hoping the following features will be preserved as-is to Rec: > >> > > >> > initial > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#styling-vocabulary-initial > >> > > >> > tts:position > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-position > >> > > >> > tts:textEmphasis > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-textEmphasis > >> > > >> > tts:ruby > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-ruby > >> > > >> > tts:rubyAlign > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyAlign > >> > > >> > tts:rubyPosition > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyPosition > >> > > >> > tts:rubyReserve (specifically, "outside") > >> > > >> > > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyReserve > >> > > >> > If everyone can kindly review, I'd like to collect everyone's opinions > >> > on > >> > these. > >> > > >> > > >> > Cheers, Dae > >> > > >> > > >> > > >> > Dae Kim | Video Engineer | Encoding Technology > >> > 9420 94f4 a834 b038 2920 34b3 38ad b632 3738 942c 942f > >> > > >> > On Thu, Jan 28, 2016 at 8:34 AM, Nigel Megitt <nigel.megitt@bbc.co.uk > > > >> > wrote: > >> >> > >> >> Thanks all for attending today's TTWG meeting. Minutes can be found > in > >> >> HTML format at https://www.w3.org/2016/01/28-tt-minutes.html > >> >> > >> >> In text format: > >> >> > >> >> [1]W3C > >> >> > >> >> [1] http://www.w3.org/ > >> >> > >> >> Timed Text Working Group Teleconference > >> >> > >> >> 28 Jan 2016 > >> >> > >> >> See also: [2]IRC log > >> >> > >> >> [2] http://www.w3.org/2016/01/28-tt-irc > >> >> > >> >> Attendees > >> >> > >> >> Present > >> >> nigel, andreas, pierre, shinjan, glenn, tmichel, dae > >> >> > >> >> Regrets > >> >> frans > >> >> > >> >> Chair > >> >> nigel > >> >> > >> >> Scribe > >> >> nigel > >> >> > >> >> Contents > >> >> > >> >> * [3]Topics > >> >> 1. [4]This Meeting > >> >> 2. [5]Action Items > >> >> 3. [6]IMSC issues > >> >> 4. [7]Commit policy on github > >> >> * [8]Summary of Action Items > >> >> * [9]Summary of Resolutions > >> >> __________________________________________________________ > >> >> > >> >> <tmichel> I will be a few minutres late ... > >> >> > >> >> <scribe> scribe: nigel > >> >> > >> >> This Meeting > >> >> > >> >> nigel: [Goes through likely topics for meeting]: Actions, IMSC > >> >> 1 issues, TTML2, possibly profiles > >> >> ... Any specific topics to cover, or AOB? > >> >> > >> >> pal: IMSC 1 issues please > >> >> > >> >> nigel: Yes > >> >> > >> >> glenn: I'd like to discuss commit policy on github > >> >> > >> >> nigel: Okay > >> >> > >> >> Action Items > >> >> > >> >> action-453? > >> >> > >> >> <trackbot> action-453 -- Thierry Michel to Schedule between > >> >> tmichel and philippe the transition to cr3 with any director > >> >> call as needed. -- due 2016-01-21 -- PENDINGREVIEW > >> >> > >> >> <trackbot> > >> >> [10]http://www.w3.org/AudioVideo/TT/tracker/actions/453 > >> >> > >> >> [10] http://www.w3.org/AudioVideo/TT/tracker/actions/453 > >> >> > >> >> tmichel: IMSC 1 CR3 is published and has been announced to AC > >> >> and Chairs, and triggered a 2 month patent exclusion > >> >> > >> >> close action-453 > >> >> > >> >> <trackbot> Closed action-453. > >> >> > >> >> tmichel: I had to extend the CR exit point to Feb 28 because we > >> >> moved the publication back by 2 days. > >> >> > >> >> nigel: Thanks > >> >> > >> >> pal: I'll modify that on github too - Feb 28? > >> >> > >> >> tmichel: Feb 28 yes > >> >> > >> >> nigel: Thanks everyone whose helped with publication of that > >> >> CR. > >> >> > >> >> action-454? > >> >> > >> >> <trackbot> action-454 -- Philippe Le Hégaret to Create stub > >> >> files to redirect from hg to github for ttml1 and ttml2 -- due > >> >> 2016-01-28 -- PENDINGREVIEW > >> >> > >> >> <trackbot> > >> >> [11]http://www.w3.org/AudioVideo/TT/tracker/actions/454 > >> >> > >> >> [11] http://www.w3.org/AudioVideo/TT/tracker/actions/454 > >> >> > >> >> glenn: I noticed on the CR3 that a message was issued, a call > >> >> for exclusions message. Is a call for exclusions a > >> >> ... multiple event or a single event? Normally in the past > >> >> process a call for exclusions only occurred on the first CR > >> >> ... but not subsequent CRs. Has that changed? > >> >> > >> >> tmichel: It's actually the com team who does that. I don't > >> >> remember - I need to check if we sent an exclusion for the > >> >> ... 2nd CR and will look into it and let you know. My > >> >> interpretation is every CR publication triggers an exclusion > >> >> ... period of 2 months, but I will investigate. > >> >> ... It makes sense because if you add functionality into the CR > >> >> version then it may result in a patent exclusion. > >> >> > >> >> glenn: I agree. > >> >> > >> >> action-454? > >> >> > >> >> nigel: Okay I guess we'll close this one. > >> >> > >> >> close action-454 > >> >> > >> >> <trackbot> Closed action-454. > >> >> > >> >> action-455? > >> >> > >> >> <trackbot> action-455 -- Glenn Adams to Update ttml2 > >> >> spec/readme to include config for keyword replacement. -- due > >> >> 2016-01-28 -- OPEN > >> >> > >> >> <trackbot> > >> >> [12]http://www.w3.org/AudioVideo/TT/tracker/actions/455 > >> >> > >> >> [12] http://www.w3.org/AudioVideo/TT/tracker/actions/455 > >> >> > >> >> action-445? > >> >> > >> >> <trackbot> action-445 -- Andreas Tai to Propose to mdolan this > >> >> addition to the profile registry document. -- due 2015-11-06 -- > >> >> OPEN > >> >> > >> >> <trackbot> > >> >> [13]http://www.w3.org/AudioVideo/TT/tracker/actions/445 > >> >> > >> >> [13] http://www.w3.org/AudioVideo/TT/tracker/actions/445 > >> >> > >> >> atai: I checked with Mike and will make a proposal for a new > >> >> column for the profile registry table that shows where > >> >> ... the profile information can be found inside the TTML > >> >> document instance for the corresponding TTML profile > >> >> specification. > >> >> ... Some are for ttp:profile attribute, or element, or > >> >> ebuttm:documentConformsToStandard element. > >> >> > >> >> mike: Andreas and I exchanged a couple of emails and it makes > >> >> sense to me. > >> >> ... I'm hopelessly behind on the profile document! > >> >> > >> >> nigel: What can I do to help? > >> >> > >> >> mike: The wiki is what I think we want to produce, in the text. > >> >> It's more about putting it into a document template > >> >> ... and using the tools to publish it in W3C. > >> >> > >> >> nigel: Thierry, would you be able to assist? > >> >> > >> >> tmichel: Yes, I'd be happy to help turn the wiki text into a > >> >> first version on github > >> >> > >> >> action-429? > >> >> > >> >> <trackbot> action-429 -- Mike Dolan to Draft a wg note for the > >> >> profile short name registry and ttml media type registration -- > >> >> due 2015-10-08 -- OPEN > >> >> > >> >> <trackbot> > >> >> [14]http://www.w3.org/AudioVideo/TT/tracker/actions/429 > >> >> > >> >> [14] http://www.w3.org/AudioVideo/TT/tracker/actions/429 > >> >> > >> >> action-429: [TTWG meeting 2016-01-28] tmichel to help this > >> >> along with a first draft on github > >> >> > >> >> <trackbot> Notes added to action-429 Draft a wg note for the > >> >> profile short name registry and ttml media type registration. > >> >> > >> >> close action-445 > >> >> > >> >> <trackbot> Closed action-445. > >> >> > >> >> IMSC issues > >> >> > >> >> pal: I'd like to start with issue #127 > >> >> > >> >> [15]https://github.com/w3c/imsc/issues/127 > >> >> > >> >> [15] https://github.com/w3c/imsc/issues/127 > >> >> > >> >> nigel: Extensibility goals not documented > >> >> > >> >> pal: The discussion is whether or how IMSC 1 can have an > >> >> opinion on IMSC 2 and how an IMSC 1 document will be > >> >> ... processed by an IMSC 2 processor and vice versa. Before we > >> >> have started on IMSC 2 it is very difficult to have a > >> >> ... good opinion. I think we should have that discussion when > >> >> we start on IMSC 2. > >> >> > >> >> glenn: The issue here is whether we address this in IMSC 1 or > >> >> wait. I'm insisting on addressing it in IMSC 1 and not > >> >> ... waiting. I agree that it needs a bit of thinking. We don't > >> >> have to refer to IMSC 2, we can simply refer to future > >> >> ... versions. At least TTML2 talks about future and past > >> >> versions. > >> >> ... In retrospect we should have given more thought to > >> >> extensibility and at least documented our goals. I'm asking > >> >> ... for informative material that describes our goals. It would > >> >> be a sad state of affairs if we cannot document our goals now. > >> >> > >> >> pal: I don't think this is as dire as you just painted it. IMSC > >> >> 1 already allows foreign vocabulary, which allows for > >> >> ... straightforward extensibility. > >> >> > >> >> glenn: It may be sufficient to describe those goals, for > >> >> example the goal of supporting vocabulary not in IMSC 1. > >> >> > >> >> pal: That's §6.2 > >> >> > >> >> glenn: I'm asking for a specifically labelled section on goals, > >> >> in an annex, the introduction or somewhere else. > >> >> > >> >> pal: Okay. I don't really know how to write that section. I'd > >> >> like to consider a concrete proposal. > >> >> > >> >> glenn: I hope people already have goals in mind and could > >> >> articulate them. > >> >> ... Foreign vocabulary is one goal. The same comments are going > >> >> to apply with #126 on interoperability. > >> >> > >> >> nigel: [opens up to group to offer options for extensibility] > >> >> > >> >> glenn: Both forward and backward compatibility come into this > >> >> category. I would hope that a goal is to be as > >> >> ... forward and backward compatible as possible, as a generic > >> >> goal that applies to most of W3C development. > >> >> ... That doesn't mean it's not possible to create a breaking > >> >> change in the future. If we think that such a breaking change > >> >> ... could occur then we could document it as a discussion > >> >> point. > >> >> > >> >> nigel: One of the points I think is probably implied is that > >> >> the purpose of the profile exercise is that extensions from > >> >> within TTML are excluded unless listed. > >> >> > >> >> glenn: Since we don't list all the features there's an > >> >> implication that unlisted features from TTML 1 are permissible > >> >> in IMSC 1, yes? > >> >> > >> >> pal: We put a significant effort in to list all TTML 1 profile > >> >> features. > >> >> > >> >> glenn: Okay, so all features from TTML Annex D are listed as > >> >> prohibited or permitted, yes? > >> >> > >> >> pal: Yes, that was the goal, and I think we achieved it. > >> >> > >> >> glenn: We could argue about if that's extensibility or > >> >> interoperability, but it is possibly both, so we could discuss > >> >> that under extensibility goals. > >> >> ... I suggest we open this up for comments over the next couple > >> >> of weeks and that I will draft a proposal based on that. > >> >> > >> >> nigel: Those comments should be on the github issue > >> >> > >> >> pal: What are we asking people to do? > >> >> > >> >> glenn: Give us opinions on what are and are not extensibility > >> >> goals. > >> >> ... I haven't written down my own thoughts on this yet. I'm > >> >> more struck by the absence of this topic than anything else. > >> >> That was my point in filing the issue. > >> >> ... I'm prepared to draft something but can't articulate my own > >> >> thinking on this right now. > >> >> > >> >> nigel: I think we should be careful to understand if we need > >> >> this or if we can build on something already in TTML1 > >> >> ... by inheritance? > >> >> > >> >> glenn: I don't think we have extensibility goals described in > >> >> TTML1 > >> >> ... which in retrospect we should have put in. > >> >> ... In TTML1 we used a QA guideline checklist. One of the > >> >> points there was a set of good practices. Number 18 > >> >> ... states that if extensibility is allowed define an extension > >> >> mechanism. > >> >> ... I suggest we review what's in IMSC 1 and TTML 1 and go from > >> >> there. > >> >> > >> >> nigel: Okay so action on everyone to complete this research and > >> >> record their goals in the issue. > >> >> > >> >> glenn: Very much the same comments apply to the > >> >> interoperability issue. > >> >> > >> >> pal: What's the time box that we have on this? > >> >> > >> >> glenn: I can respond by mid-Feb with some material. > >> >> > >> >> nigel: Okay, that sounds like 2 weeks to note extensibility and > >> >> interoperability goals in the github issues. > >> >> > >> >> pal: How are we doing on #111 and #114? > >> >> > >> >> glenn: I've got to draft some material based on a conversation > >> >> I had with Nigel, where we think we may be able to resolve both > >> >> of those. > >> >> ... Mid-Feb is reasonable for those too. > >> >> > >> >> pal: #125 [16]https://github.com/w3c/imsc/issues/125 Unable to > >> >> normatively determine non-conformance when testing content > >> >> constraints. > >> >> > >> >> [16] https://github.com/w3c/imsc/issues/125 > >> >> > >> >> glenn: At present IMSC 1 specifies that if a document is not > >> >> conformant then behaviour is undefined. Correct? > >> >> > >> >> pal: Correct. The document does not specify a normative > >> >> behaviour in the presence of a non-conformant document. > >> >> > >> >> glenn: A couple of points: 1. Since all behaviour re > >> >> non-conformance is unspecified then it is impossible to > >> >> normatively > >> >> ... test non-conformance because any outcome is possible, from > >> >> aborting to ignoring and anything in between. > >> >> ... I'm not happy with that state of affairs. Part 2, which I > >> >> did make a proposal for, is to introduce the concept of a > >> >> ... validating processor and to allow for some normative > >> >> behaviour in the face of non-conformance if and when the > >> >> ... IMSC processor is also a validating processor. So an IMSC > >> >> transformation or validation processor that also supports > >> >> ... validation and it is enabled then it is possible to define > >> >> some constraints on non-conformance. > >> >> > >> >> atai: I thought the conclusion here from previous meetings when > >> >> we discussed this is that handling of non-conformant > >> >> ... files is out of spec and I agree with that. What Glenn > >> >> wants to define is behaviour on encountering non-conformant > >> >> documents. > >> >> ... I think that's out of scope of the spec. The topic came up > >> >> before and from what I read of the minutes the conclusion > >> >> ... was out of scope. > >> >> > >> >> pal: That's my recollection, but it sounds like Glenn is > >> >> proposing something a little narrower, only for validating > >> >> processors. > >> >> ... So for those who choose to describe processors as > >> >> validating then this is the behaviour. > >> >> > >> >> glenn: That's right. I don't disagree with Andreas but I think > >> >> we can do better than that at little or no cost to the > >> >> specification. > >> >> ... For example the TTT toolset has a presentation engine in > >> >> it. It performs validation processing as a precursor to > >> >> ... presentation. It's an existing implementation (also of a > >> >> transformation processor) that does implement the optional > >> >> ... features of validation. So we can go further than saying > >> >> it's completely out of scope and having normative > >> >> ... language that allows us to introduce defined behaviour. > >> >> > >> >> pal: The particular thing here is that it's a class of > >> >> processors described as validating processors. > >> >> > >> >> glenn: Yes, TTML2 introduces these all formally along with some > >> >> specific vocabulary for controlling it. I didn't want > >> >> ... to inject that into this proposal because that would be > >> >> going too far, but I took the semantics of what we're > >> >> ... proposing and put them into a form that we could adopt in > >> >> IMSC 1. > >> >> > >> >> atai: Thank you for the clarification. It is of course a > >> >> different use case. I would like to see the concrete proposal. > >> >> ... There are of course existing possibilities to check > >> >> conformance, for example using an XML schema. This already > >> >> ... has a defined behaviour for how to identify > >> >> non-conformance. I'm not sure if we should also define > >> >> behaviour for > >> >> ... QC processes of TTML. > >> >> > >> >> glenn: Take a look at #125 because there is a proposed set of > >> >> language there. > >> >> > >> >> Commit policy on github > >> >> > >> >> glenn: There are two kinds of policies that are commonly used > >> >> in development - Review Then Commit, when a > >> >> ... consensus approval is obtained prior to a commit. Then > >> >> there's Commit Then Review, which allows a > >> >> ... retroactive veto. In the history of this group all of the > >> >> work on TTML1 and TTML2 in Mercurial and CVS was done > >> >> ... on a Commit Then Review (CTR) lazy consensus process. It > >> >> was based on the editor to decide when to commit > >> >> ... and then notify the group and make sure that they had log > >> >> info to give them a chance to review post facto and > >> >> ... object if necessary. Most teams follow a CTR process > >> >> because it provides the least barriers to making changes. > >> >> ... It can result in more bugs potentially. My experience is > >> >> I've worked with both kinds of processes. With github > >> >> ... which has a Pull Request mechanism it is possible to > >> >> snapshot the changes and call them out for review. We > >> >> ... discussed and agreed the move to github in Sapporo and > >> >> talked about the review process but I don't recall doing > >> >> ... so in depth. At the time I remember thinking it should be > >> >> up to the Editor to decide how to use that facility. I never > >> >> ... anticipated changing from CTR to RTC. Recently both Nigel > >> >> and Pierre have in the context of IMSC 1 been following > >> >> ... a RTC process in their thinking. I would object to that for > >> >> TTML2. I might be willing to agree to it for other work. > >> >> ... I find it a strong barrier to process. For example right > >> >> now I have 4 different issues that Pierre has delegated to me > >> >> ... to create PRs. All of those fixes are going to change the > >> >> same lines of code. > >> >> > >> >> pal: I think there's a misunderstanding - you can create a PR > >> >> that covers multiple issues, and we've done that in the > >> >> ... past. > >> >> > >> >> glenn: I agree that's possible. > >> >> > >> >> nigel: github also provides a tool for merging work in other > >> >> branches to resolve the clashes. > >> >> > >> >> glenn: I agree there are tools there but it's much more awkward > >> >> and difficult to do that. My basic point is that > >> >> ... we don't have a firm consensus on CTR or RTC as a policy. > >> >> Secondly even if we are using RTC on e.g. IMSC 1 I don't > >> >> ... think it should be a blanket policy but up to the Editor to > >> >> decide what policy to use. For trivial changes there's > >> >> ... no reason to follow the more time consuming process. > >> >> > >> >> atai: I think we should check again what we discussed at TPAC. > >> >> I think we explicitly had some discussion about the > >> >> ... new policy with github and I thought we agreed but I'm not > >> >> sure. > >> >> > >> >> nigel: We did discuss this in Sapporo and I'm pretty sure we > >> >> did agree that. For WDs we always followed a RTC process > >> >> ... and said that to reduce the time between ED updates and WD > >> >> publications and to use the automated WD publication > >> >> ... tool we would use PRs. > >> >> > >> >> glenn: I do recall saying that I wouldn't be happy to adopt > >> >> this for TTML2. > >> >> > >> >> nigel: I'm happy to review the notes on this and return to it > >> >> as a topic. In the meantime I would also like plh's views > >> >> ... and I would myself strongly recommend that we use pull > >> >> requests for everything including TTML2. > >> >> > >> >> glenn: I don't mind using pull requests but I object to a 2 > >> >> week period before a merge is permitted. > >> >> ... I think it should be up to the Editor or possibly the Chair > >> >> to decide to merge if a change is non controversial and > >> >> ... not to impose a 2 week delay on all PRs. > >> >> > >> >> nigel: That's coincident with what we said in Sapporo. There > >> >> may be a middle ground there that is actually acceptable. > >> >> > >> >> glenn and pal: [discussion without conclusion on who should be > >> >> allowed to merge pull requests] > >> >> > >> >> nigel: We're out of time now so I'll adjourn. An hour again, > >> >> same time next week. Thanks everyone [adjourns meeting] > >> >> > >> >> Summary of Action Items > >> >> > >> >> Summary of Resolutions > >> >> > >> >> [End of minutes] > >> >> __________________________________________________________ > >> >> > >> >> > >> >> Minutes formatted by David Booth's [17]scribe.perl version > >> >> 1.144 ([18]CVS log) > >> >> $Date: 2016/01/28 16:33:11 $ > >> >> > >> >> [17] > http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > >> >> [18] http://dev.w3.org/cvsweb/2002/scribe/ > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> ---------------------------- > >> >> > >> >> 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 Friday, 29 January 2016 17:34:13 UTC