IMSC Hypothetical Render Model

W3C Working Draft 22 March 2022

Abstract

This specification specifies an Hypothetical Render Model (HRM) that constrains the complexity of documents that conform to any of the TTML Profiles for Internet Media Subtitles and Captions ([IMSC]).

The model is not intended as a specification of the processing requirements for implementations. For instance, while the model defines a glyph buffer for the purpose of limiting the number of glyphs displayed at any given point in time, it neither requires the implementation of such a buffer, nor models the sub-pixel glyph positioning and anti-aliased glyph rendering that can be used to produce text output.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Timed Text Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 2 November 2021 W3C Process Document.

This specification specifies an Hypothetical Render Model (HRM) that constrains the complexity of a IMSC Document Instance.

This specification uses the same conventions as [IMSC].

character. The character code property of a Character Information Item.

Note

The term character is for practical purposes the same as a code point.

code point. As defined by [i18n-glossary].

empty ISD. An Intermediate Synchronic Document with no presented region.

error. A failure to conform to the constraints defined by this specification.

IMSC Document Instance. A Document Instance that conforms to any profile defined in any edition of [IMSC].

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key word SHALL in this document is to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Unless noted otherwise, this specification applies to an IMSC Document Instance.

A sequence of consecutive Intermediate Synchronic Documents conforms to the Hypothetical Render Model if is processed without error.

Note

Applying the Hypothetical Render Model to a Document Instance that is not an IMSC Document Instance yields results that might not reflect the complexity of the Document Instance.

This section is non-normative.

The objective of the HRM is to allow subtitle and caption authors and providers to verify that the content they provide does not exceed defined complexity levels, so that playback systems can render the content synchronized with the author-specified display times.

Playback systems include desktop computers, mobile devices and home theatre devices.

Note

The HRM is not a new concept: it has been included in all versions and editions of [IMSC] and has remained substantially unchanged. It is refactored herein to simplify document maintenance.

IMSC Document Instances are typically authored by a first party and rendered by a second party. Unless both parties agree on the maximum complexity of a IMSC Document Instance, it is likely that:

an IMSC Document Instance authored by a first party will exceed the capabilities of the presentation processor of a second party, resulting in an incomplete presentation where some subtitles or captions might be missing or might be presented too late;
a first party authors only extremely simple IMSC Document Instances in an attempt to ensure a complete presentation across all renderers, resulting in a lower quality presentation;
a second party over-provisions their presentation processor in order to ensure a complete presentation of all IMSC Document Instances, resulting in increased run-time resource usage, code complexity, etc.; or
one presentation processor becomes the de-facto reference to determine whether the presentation of a IMSC Document Instance will succeed, at the expense of other renderers and consistency of presentation.

The HRM prevents incomplete presentations of IMSC Instance Documents. — Figure 1 The HRM allows authors and implementers of presentation processors to agree on the maximum complexity of IMSC Document Instances.

As illustrated in Figure 1, by defining a method (the HRM) to compute a proxy for the complexity of an IMSC Document Instance and specifying a complexity limit based on such proxy:

authors can ensure that their IMSC Document Instances do not exceed this limit;
implementers can design their presentation processors to maximize the likelihood that they will be able to render correctly all IMSC Document Instances that do not exceed this limit; and
audiences can expect subtitle and caption presentation to match the authorial intention.

The HRM supplements the syntactic and structural constraints imposed in [IMSC] by imposing constraints on the contents of the presentation.

Because of the temporal and spatial variability of subtitles and captions across types of content, territories and languages, it is not possible to limit the complexity of an IMSC Document Instance using only average values.

An average-based constraint of 840 characters per minute could be met in multiple ways, with different rendering complexities. Contrast two potential approaches:

In the first, 5 characters are presented for a fraction of a second, followed by 835 characters that are then presented for over 59 seconds. This generates a high rendering complexity for the 835 characters, since there is only a brief time available to paint them.

In the second, 210 characters must be painted every 15 seconds, giving 15 seconds to prepare for the next presentation. This has a much lower rendering complexity.

The HRM achieves a more accurate representation of the complexity of an IMSC Document Instance at any given time by taking into account its past complexity in addition to its instantaneous complexity. The same approach is commonly used in video to limit bitstream complexity, e.g., the Hypothetical Reference Decoder (HRD) specified in [iso14496-10].

The HRM defines a simple model for the rendering of subtitles and captions, and uses the time it takes to render subtitles and captions according to that model as a proxy for the complexity of the subtitles and captions. Rendering includes drawing region backgrounds, rendering and copying text, and decoding and copying images. Complexity is then limited by requiring that the time to render one subtitle or caption is shorter than the time elapsed since the previous subtitle or caption.

This simple model requires only a static analysis of the IMSC Document Instance, requires no fetching of external resources and does not require the IMSC Document Instance to be actually rendered. Several simplifying assumptions are made to achieve this. For example, the model assumes that each character is drawn independently, and accounts for that assumption being, in many cases, false, by assigning different render speeds for different scripts. In general the model is not intended to capture the actual time that an implementation takes to render subtitles and captions, but rather scale with it: a document that is twice as complex according to the model would require roughly twice as many resources to actually render.

The HRM is typically used prior to distribution of the IMSC Document Instance to the end-user, as an integral part of authoring and as a quality check before distribution.

When the HRM is used, the consequences of an IMSC Document Instance exceeding the HRM limits depends on the context:

an authoring system might, for example, flag the specific point in time where the HRM limits were exceeded;
the ingest component of a streaming platform might outright reject the IMSC Document Instance.

The HRM is not intended to be used when the IMSC Document Instance is presented to end-users since:

end-users are not concerned with a technical complexity measure, just as they are not concerned with video bit-rate, but instead with whether the presentation is successful;
a presentation processor cannot generally reduce the complexity of a IMSC Document Instance without impacting the presentation.

This section is non-normative.

The model illustrated in Figure 2 operates on successive Intermediate Synchronic Documents obtained from an input IMSC Document Instance, and uses a simple double buffering model: while an Intermediate Synchronic Document E_n is being painted into Presentation Buffer P_n (the "front buffer" of the model), the previous Intermediate Synchronic Document E_n-1 is available for display in Presentation Buffer P_n-1 (the "back buffer" of the model).

The model specifies a (hypothetical) time required for completely painting an Intermediate Synchronic Document as a proxy for complexity. Painting includes drawing region backgrounds, rendering and copying glyphs, and decoding and copying images. Complexity is then limited by requiring that painting of Intermediate Synchronic Document E_n completes before the end of Intermediate Synchronic Document E_n-1.

Whenever applicable, constraints are specified relative to Root Container Region dimensions, allowing subtitle sequences to be authored independently of Related Video Object resolution.

To enable scenarios where the same glyphs are used in multiple successive Intermediate Synchronic Documents, e.g. to convey a CEA-608/708-style roll-up (see [CEA-608] and [CEA-708]), the Glyph Buffers G_n and G_n-1 store rendered glyphs across Intermediate Synchronic Documents, allowing glyphs to be copied into the Presentation Buffer instead of rendered, a more costly operation.

Similarly, Decoded Image Buffers D_n and D_n-1 store decoded images across Intermediate Synchronic Documents, allowing images to be copied into the Presentation Buffer instead of decoded.

The Presentation Compositor SHALL render in Presentation Buffer P_n each successive Intermediate Synchronic Document E_n using the following steps in order:

clear the pixels of the entire Root Container Region, unless n=0 or E_n-1 is an empty ISD;
paint, according to stacking order, all background pixels for each region;
paint all pixels for background colors associated with text or image subtitle content; and
paint the text or image subtitle content.

The Presentation Compositor SHALL start rendering E_n:

at the presentation time of E_m, where E_m is the closest ISD for which 0<m<n and E_m-1 is not an empty ISD, if the presentation time of E_n minus that of E_m is less than IPD; or
at the presentation time of E_n minus IPD, otherwise.

Note

The Presentation Compositor never renders an ISD more than IPD ahead of its presentation time and treats sequences of empty ISDs as a single ISD.

ISD rendering and presentation times. — Figure 3 illustrates the rendering and presentation of Intermediate Synchronic Documents by the Presentation Compositor. The Presentation Compositor renders E_n at the presentation time of E_n-2 since E_n-1 is an empty ISD. In contrast, the Presentation Compositor renders E_n-2 at the presentation time of E_n-3 since E_n-4 is not an empty ISD. Finally, E₀ is rendered at the presentation time of E₀ minus IPD.

The duration DUR(E_n) for painting an Intermediate Synchronic Document E_n in the Presentation Buffer P_n SHALL be:

DUR(E_n) = S(E_n) / BDraw + DUR_T(E_n) + DUR_I(E_n)

where

S(E_n) is the total normalized drawing area for Intermediate Synchronic Document E_n, as specified in 8. Paint Regions;
BDraw is the normalized background drawing performance factor;
DUR_T(E_n) is the duration, in seconds, for painting the text subtitle content for Intermediate Synchronic Document E_n, as specified in Section 10. Paint Text; and
DUR_I(E_n) is the duration, in seconds, for painting the image subtitle content for Intermediate Synchronic Document E_n, as specified in Section .

The contents of the Presentation Buffer P_n SHALL be transferred instantaneously to Presentation Buffer P_n-1 at the presentation time of Intermediate Synchronic Document E_n, making the latter available for display.

Note

It is possible for the contents of Presentation Buffer P_n-1 to never be displayed. This can happen if Presentation Buffer P_n is copied twice to Presentation Buffer P_n-1 between two consecutive video frame boundaries of the Related Video Object.

It SHALL be an error for the Presentation Compositor to fail to complete painting pixels for E_n before the presentation time of E_n.

Unless specified otherwise, the following table SHALL specify values for IPD and BDraw.

Parameter	Initial value
Initial Painting Delay (IPD)	1 s
Normalized background drawing performance factor (BDraw)	12 s^-1

Note

BDraw effectively sets a limit on fillings regions - for example, assuming that the Root Container Region is ultimately rendered at 1920×1080 resolution, a BDraw of 12 s^-1 would correspond to a fill rate of 1920×1080×12/s=23.7×2²⁰pixels s^-1.

Note

IPD effectively sets a limit on the complexity of any given Intermediate Synchronic Document.

The total normalized drawing area S(E_n) for Intermediate Synchronic Document E_n SHALL be

S(E_n) = CLEAR(E_n) + PAINT(E_n )

where CLEAR(E_n) = 0 if n=0 or E_n-1 is an empty ISD, and CLEAR(E_n) = 1 otherwise.

Note

To ensure consistency of the Presentation Buffer, a new Intermediate Synchronic Document requires clearing of the Root Container Region.

PAINT(E_n) SHALL be the normalized area to be painted for all regions that are used in Intermediate Synchronic Document E_n according to:

PAINT(E_n) = ∑_{R_i∈R_p} NSIZE(R_i) ∙ NBG(R_i)

where R_p SHALL be the set of presented regions in the Intermediate Synchronic Document E_n.

NSIZE(R_i) SHALL be given by:

NSIZE(R_i) = (width of R_i ∙ height of R_i ) ÷ (Root Container Region height ∙ Root Container Region width)

Example 1

For a region R_i in with tts:extent="250px 50px" within a Root Container Region with tts:extent="1920px 1080px", NSIZE(R_i) ≈ 0.00603.

NBG(R_i) SHALL be the total number of elements within the tree rooted at region R_i that satisfy the following criteria:

the element is either a region, body, div, p or span; and
the opacity of the computed value of tts:backgroundColor is not 0.

Issue 5: span elements are included in NBG(R_i)

NBG(R_i) counts the number of tts:backgroundColor attributes specified span elements.

In a common scenario illustrated below, this results in the complexity of painting (relatively small) span backgrounds to be equal to painting the background of (relatively much larger) region that essentially fills the root container.

This can be addressed by excluding span from the NBG(R_i) computation, and instead including tts:backgroundColor in the list of glyph properties at https://www.w3.org/TR/ttml-imsc1.1/#paint-text.

Note

An element and its parent that satisfy the criteria above and share identical computed values of tts:backgroundColor are counted as two distinct elements for the purpose of computing NBG(R_i).

Note

The set element is not included in the computation of NBG(R_i). While it can affect the computed values of tts:backgroundColor, it is removed during Intermediate Synchronic Document construction.

The Presentation Compositor SHALL paint into the Presentation Buffer P_n all visible pixels of presented images of Intermediate Synchronic Document E_n.

For each presented image, the Presentation Compositor SHALL either:

if an identical image is present in Decoded Image Buffer D_n, copy the image from Decoded Image Buffer D_n to the Presentation Buffer P_n using the Image Copier; or
if an identical image is present in Decoded Image Buffer D_n-1, i.e. an identical image was present in Intermediate Synchronic Document E_n-1, copy using the Image Copier the image from Decoded Image Buffer D_n-1 to both the Decoded Image Buffer D_n and the Presentation Buffer P_n; or
otherwise, decode the image using the Image Decoder the image into the Presentation Buffer P_n and Decoded Image Buffer D_n.

Two images SHALL be identical if and only if they reference the same encoded image source.

The duration DUR_I(E_n) for painting images of an Intermediate Synchronic Document E_n in the Presentation Buffer SHALL be as follows:

DUR_I(E_n) = ∑_{I_i ∈ I_c} NRGA(I_i) / ICpy + ∑_{I_j ∈ I_d} NSIZ(I_j) / IDec

where

I_c is the set of images copied when painting Intermediate Synchronic Document E_n;
I_d is the set of images decoded when painting Intermediate Synchronic Document E_n;
IDec is the image decoding rate; and
ICpy is the normalized image copy performance factor.

NRGA(I_i) is the Normalized Image Area of presented image I_i and SHALL be equal to:

NRGA(I_i)= (width of I_i ∙ height of I_i ) ÷ ( Root Container Region height ∙ Root Container Region width )

NSIZ(I_i) SHALL be the number of pixels of presented image I_i.

The contents of the Decoded Image Buffer D_n SHALL be transferred instantaneously to Decoded Image Buffer D_n-1 at the presentation time of Intermediate Synchronic Document E_n.

The total size occupied by images stored in Decoded Image Buffers D_n or D_n-1 SHALL be the sum of their Normalized Image Area.

The size of Decoded Image Buffers D_n or D_n-1 SHALL be the Normalized Decoded Image Buffer Size (NDIBS).

Unless specified otherwise, the following table SHALL specify ICpy, IDec, and NDBIS.

Parameter	Initial value
Normalized image copy performance factor (ICpy)	6
Image Decoding rate (IDec)	1 × 2²⁰ pixels s^-1
Normalized Decoded Image Buffer Size (NDIBS)	0.9885

In the context of this section, a glyph is a tuple consisting of (i) one character and (ii) the computed values of the following style properties:

tts:color
tts:fontFamily
tts:fontSize
tts:fontStyle
tts:fontWeight
tts:textDecoration
tts:textOutline
tts:textShadow

Note

In the case where a property is prohibited in a profile of [IMSC], the computed value of the property specified in [ttml2] can be used.

Note

The Hypothetical Render Model defines a one-to-one mapping between characters and glyphs (using the definition of glyph from this document). While a one-to-one mapping between code points and glyphs (using the definition of glyph from [i18n-glossary]) is common in some scripts (such as the Latin script), the actual relationship is more complex. Some scripts, such as Arabic, use different glyphs for a given character, depending on its position in a word. Some scripts require combining marks or use a sequence of code points to form a glyph. Cases exist where a given sequence of code points can have different glyph representations depending on context. This complexity is accounted for by reducing the performance of the glyph buffer for scripts where a one-to-one mapping is not the general rule (see GCpy below).

For each glyph associated with a character in a presented region of Intermediate Synchronic Document E_n, the Presentation Compositor SHALL:

if an identical glyph is present in Glyph Buffer G_n, copy the glyph from Glyph Buffer G_n to the Presentation Buffer P_n using the Glyph Copier; or
if an identical glyph is present in Glyph Buffer G_n-1, i.e. an identical glyph was present in Intermediate Synchronic Document E_n-1, copy using the Glyph Copier the glyph from Glyph Buffer G_n-1 to both the Glyph Buffer G_n and the Presentation Buffer P_n; or
otherwise render using the Glyph Renderer the glyph into the Presentation Buffer P_n and Glyph Buffer G_n.

Figure 4 Example of Presentation Compositor Behavior for Text Rendering

The duration DUR_T(E_n) for rendering the text of an Intermediate Synchronic Document E_n in the Presentation Buffer is as follows:

DUR_T(E_n) = ∑_{g_i ∈ Γ_r} NRGA(g_i) / Ren(g_i) + ∑_{g_j ∈ Γ_c} NRGA(g_j) / GCpy

where

Γ_r is the set of glyphs rendered into the Presentation Buffer P_n using the Glyph Renderer in Intermediate Synchronic Document E_n;
Γ_c is the set of glyphs copied to the Presentation Buffer P_n using the Glyph Copier in Intermediate Synchronic Document E_n;
Ren(g_i) is the text rendering performance factor for glyph g_i; and
GCpy is the normalized glyph copy performance factor.

The Normalized Rendered Glyph Area NRGA(g_i) of a glyph g_i SHALL be equal to:

NRGA(g_i) = (fontSize of g_i as percentage of Root Container Region height)²

Note

NRGA(G_i) does not take into account decorations (e.g. underline), effects (e.g. outline) or actual typographical glyph aspect ratio. An implementation can determine an actual buffer size needs based on worst-case glyph size complexity.

The contents of the Glyph Buffer G_n SHALL be copied instantaneously to Glyph Buffer G_n-1 at the presentation time of Intermediate Synchronic Document E_n.

It SHALL be an error for the sum of NRGA(g_i) over all glyphs Glyph Buffer G_n to be larger than the Normalized Glyph Buffer Size (NGBS).

Unless specified otherwise, the following table specifies values of GCpy, Ren and NGBS.

Normalized glyph copy performance factor (GCpy)
Script property, as defined at [UAX24], for the character of g_i	GCpy
`Latin`, `Greek`, `Cyrillic`, `Hebrew` or `Common`	12
any other value	3
Text rendering performance factor Ren(G_i)
Script property, as defined at [UAX24], for the character of g_i	Ren(G_i)
`Han`, `Katakana`, `Hiragana`, `Bopomofo` or `Hangul`	0.6
any other value	1.2
Normalized Glyph Buffer Size (NGBS)
1

Note

While DUR_T(E_n) is not affected, the choice of font by the presentation processor can increase actual rendering complexity at time of presentation. For instance, a cursive font might select different glyphs for a given grapheme (in order to maintain joining or for the start/end of the word) even in the Latin script. Conversely the rendering of scripts that fall in the any other value category can in practice achieve performance comparable to, say, the Latin script.

Example 2

Setting a Normalized Glyph Buffer Size effectively sets a limit on the total number of distinct glyphs present in any given Intermediate Synchronic Document E_n. For example, assuming a maximum Normalized Glyph Buffer Size of 1 and the default tts:fontSize of 1c are used, the font size relative to the Root Container Region height is 1/15 , and the maximum number of distinct glyphs that can be buffered is 1÷(1÷15)²=225 glyphs.

Example 3

GCpy effectively sets a limit on animating text. For example, assuming that the Root Container Region is ultimately rendered at 1920×1080 resolution and no regions need to have background color painted (so only a CLEAR(E_n) operation is required for the normalized drawing area for the Intermediate Synchronic Document), a GCpy and BDraw of 12 s^-1 would mean that a group of 160 glyphs with a tts:fontSize equal to 5% of the Root Container Region height could be moved at most approximately 12 s^-1 ÷ (1 + ( 160 × 0.05² )) = 8.6 times per second.

This section is non-normative.

In a system where IMSC Document Instances are expected to conform to the Hypothetical Render Model, an IMSC Document Instance that does not conform to the Hypothetical Render Model might negatively impact accessibility during presentation of the IMSC Document Instance and its associated content.

This specification does not attempt to model any additional complexity for presentation processors that might arise due to the user customisation of presentation, for example as described by [media-accessibility-reqs]; such user customisation is not defined by [IMSC].

Implementers of presentation processors that support user customisation of presentation should ensure that those processors are able to present IMSC Document Instances that conform to the Hypothetical Render Model, even if the customisation effectively increases the complexity of presentation.

This section is non-normative.

This specification has no inherent security or privacy implications.

The algorithm defined within this specification is used for static analysis of a resource. This specification does not define any protocol or interface for obtaining such a resource, and it does not define any interface for exposing the results of the analysis. No personal or sensitive information is processed as part of the algorithm, other than any such information that might happen to be part of the IMSC Document Instance being analysed. No information is exposed by the algorithm to any origin. No scripts are loaded or processed as part of the algorithm and no links to external resources are dereferenced.

Implementers of this specification should capture and meet privacy and security requirements for their intended application. For example, an implementation could, when reporting on an error encountered during processing of an IMSC Document Instance, include a section of the content of an IMSC Document Instance to elaborate the error. If that content could include sensitive or personal information, the implementation should ensure that any such output is provided using appropriately secure protocols. No such reporting is defined or required by this specification.

This section is non-normative.

This specification does not define how, or even if, errors should be reported.

For example, an implementation could stop on the first error encountered, or continue to process the IMSC Document Instance and report every error. Or an implementation could exit with an appropriate status code without reporting any details at all.

This specification does not define any runtime exceptions, or how such exceptions should be handled.

This section is non-normative.

[i18n-glossary]: Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 11 February 2022. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
[IMSC]: TTML Profiles for Internet Media Subtitles and Captions. World Wide Web Consortium (W3C). URL: https://www.w3.org/TR/ttml-imsc/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[ttml2]: Timed Text Markup Language 2 (TTML2). Glenn Adams; Cyril Concolato. W3C. 8 November 2018. W3C Recommendation. URL: https://www.w3.org/TR/2018/REC-ttml2-20181108/
[UAX24]: Unicode Script Property. Ken Whistler. Unicode Consortium. 27 August 2021. Unicode Standard Annex #24. URL: https://www.unicode.org/reports/tr24/tr24-32.html

[CEA-608]: CTA 608-E, Line-21 Data Services. Consumer Technology Association. URL: https://www.techstreet.com/standards/cta-608-e-r2014?product_id=1815447
[CEA-708]: CTA 708-D, Digital Television (DTV) Closed Captioning. Consumer Technology Association. URL: https://www.techstreet.com/standards/cta-708-d?product_id=1815448
[iso14496-10]: Information technology — Coding of audio-visual objects — Part 10: Advanced video coding. ISO/IEC. Under development. URL: https://www.iso.org/standard/83529.html
[media-accessibility-reqs]: Media Accessibility User Requirements. Shane McCarron; Michael Cooper; Mark Sadecki. W3C. 3 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/2015/NOTE-media-accessibility-reqs-20151203/

IMSC Hypothetical Render Model

Abstract

Status of This Document

1. Scope

2. Documentation Conventions

3. Terms and Definitions

4. Conformance

5. Introduction

5.1 Objective

5.2 Why limit the complexity of IMSC Document Instances?

5.3 Why is the HRM needed to limit complexity?

5.4 How does the HRM measure and limit complexity?

5.5 Where is the HRM used?

6. Architecture

7. General

8. Paint Regions

9. Paint Images

10. Paint Text

A. Accessibility Considerations

A.1 Impact of non-conformance

A.2 User customisation of presentation

B. Privacy and Security Considerations

B.1 General

B.2 Implementation considerations

C. Error Reporting and Exception Handling

C.1 Error Reporting

C.2 Exception Handling

D. Acknowledgements

E. Summary of substantive changes

F. References

F.1 Normative references

F.2 Informative references