Defer to TTML2 for security and privacy considerations

[palemieux]

Closes #280

[nigelmegitt]

This change is significant in that it both removes any IMSC-specific text and imports all of the security and privacy considerations of TTML2, even those that do not apply.

Happy to discuss this on the call this week, but it seems to me that we need to:

1. Call out the security and privacy implications of extension features added in this specification, to which the TTML2 considerations by definition do not apply

2. Call out any considerations listed in TTML2 that do not apply here because they are profiled out, for example the one about hyperlinking mechanisms.

[palemieux]

@nigelmegitt I see no benefit in spending time subsetting the TTM2 privacy and security considerations. Can you list them?

[nigelmegitt]

@palemieux You mean you don't want to and you're asking me to do it?

[palemieux]

@nigelmegitt Oh no. I mean I do not think it is worth anyone doing it :)

[nigelmegitt]

@palemieux I disagree - if we know that a consideration does not apply, we should clarify that: it is a potential benefit of using the profile.

[palemieux]

@nigelmegitt Alright. Please go ahead then.

[nigelmegitt]

As discussed in the TTWG call just now the following TTML2 considerations do not apply to IMSC 1.1:

• P.7 Access to Processing State
• P.8 Hyperlinking Mechanisms

So add text such as:

_With the exception of the following considerations the privacy and security considerations of TTML2 apply. Those exceptions are:

• P.7 Access to Processing State does not apply since the condition attribute is not supported.
• P.8 Hyperlinking Mechanisms does not apply since the xlink linking mechanism is not supported._

[nigelmegitt]

Happy with the words - do we need to format the terms condition and xlink to look like code?

[nigelmegitt]

Looks good to me.