W3C home > Mailing lists > Public > public-tt@w3.org > November 2013

TTML Minutes for 11/11/13

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 21 Nov 2013 16:27:47 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <CEB3E4F6.14CEF%nigel.megitt@bbc.co.uk>
Minutes for 11/11/13 can be found at: http://www.w3.org/2013/11/11-tt-minutes.html


      [1] http://www.w3.org/

                               - DRAFT -

                Timed Text Working Group Teleconference

11 Nov 2013

   See also: [2]IRC log

      [2] http://www.w3.org/2013/11/11-tt-irc




          nigel, pal


     * [3]Topics
         1. [4]TTML profiles
         2. [5]profiles (continued)
         3. [6]IMSC
     * [7]Summary of Action Items

   <trackbot> Date: 11 November 2013

TTML profiles



      [8] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/design/TPAC2013-TTMLProfiles.pdf

   <nigel> scribeNick: nigel

   glenn: describes TTML1 Profiles
   ... using slides from link above
   ... Nobody has actually used the "used" value to my knowledge.
   ... Instead people just used "required"
   ... to mean both supported and enabled.

   pal: do we know in practice how many documents include profile
   definitions inline?

   glenn: no we don't know.

   pal: sdp-us, cff-tt and ebu-tt don't.

   nigel: can Profiles be combined when defined internally,
   externally or any combination?

   glenn: any combination

   nigel: Are external references required to be resolved?

   glenn: they 'should' be resolvable but it's not a mandatory

   On the 'what's missing' slide

   Profile Designator Proposal

   Checking which issue or action is related to this problem

   pal: creating an action for this

   glenn: this designator is just a label, doesn't imply anything
   about schemas etc

   hello plh

   pal: this binds the profile with this URI, unambiguously

   nigel: it's clear for linking profiles with labels but it's
   another different problem to define which profiles any
   particular document conforms to.

   glenn: all this designator attribute does is allows the profile
   definition document to create a machine-readable label.


   <trackbot> issue-297 -- Include Profile Designator in Profile
   Definition Document -- raised


      [9] http://www.w3.org/AudioVideo/TT/tracker/issues/297

   glenn: proposes that we complete these issues if there are no
   objections by December 1st

   <glenn> PROPOSED RESOLUTION: to adopt @designator attribute on
   ttp:profile as described in presentation, to be finalized by


   <trackbot> issue-266 -- add ability for instance documents to
   declare what profile(s) it conforms to -- open


     [10] http://www.w3.org/AudioVideo/TT/tracker/issues/266

   On slide Content Profile Proposal (2) tt:root -> tt:tt

   <glenn> s/tt:root/tt:tt/ in the presentation

   <glenn> <ttp:profile type="content" use="ttml-full-content"/>

   glenn: scope of ttp:validation is global for the whole
   document, and all referenced profiles.

   pal: can you type an example of what it would look like to
   specify that a document conforms to multiple content profiles

   nigel: have added reference to this proposal on issue-266

   <glenn> <tt ...>

   <glenn> <head>

   <glenn> <ttp:profile type="content"

   <glenn> <ttp:profile type="content"

   <glenn> </head>

   <glenn> </tt>

   pal: that satisfies the requirement for specifying multiple
   conformant document content profiles.

   glenn: there's another way too, a variant on it.

   <glenn> <tt ...>

   <glenn> <head>

   <glenn> <ttp:profile type="content">

   <glenn> <ttp:profile type="content"

   <glenn> <ttp:profile type="content"

   <glenn> </ttp:profile>

   <glenn> </head>

   <glenn> </tt>

   glenn: this allows nested definitions of a content profile.

   pal: Based on the use cases I've heard of this goes well beyond
   the requirement.
   ... Can we document the reason behind the extra complexity?

   <glenn> <tt ttp:profile="dfxp-presentation"/>

   glenn: this is the current mechanism. It can only take one URI
   not a list.

   <glenn> <tt ttp:contentProfile="dfxp-presentation-content"/>

   glenn: If we added a content profile that does something
   similar then we couldn't have a list.
   ... By using the more advanced mechanism this could reference
   multiple content profiles.

   pal: have you considered extending the current mechanism to be
   a list, which would be backward compatibility

   glenn: it sounds like a reasonable extension.
   ... One argument is that it facilitates adding in the profile
   features to the document.
   ... we often end up with multiple forms as shorthands, and this
   does have associated cost

   pal: what about the idea of 'if you use content profile or
   profile attribute' you can't use the other.

   glenn: we already have that in TTML1 in 5.2

   group reviews current specification

   glenn: it is currently well defined. The ttv verifier tool will
   warn if both are present, or neither.
   ... I view the attribute as a shorthand for the element.
   ... 2 proposals. First is to allow profiles and profile
   attributes to allow multiple designator.
   ... Second is to ensure that it's possible for a content
   profile definition to proscribe use of the profile element
   while requiring use of the profile attribute.

   nigel: there's another issue in that people define profiles by
   behaviour within text in a specification document not just as
   ttml profile designators

   pal: also interested in that.

   glenn: are there any immediate objections?

   nigel: this does appear to meet the needs of issue-266

   glenn: this goes beyond as it adds validation semantics

   nigel: we should be careful to avoid confusion in readers
   between optional/required feature designators and the
   validation action

   <glenn> ACTION: glenn to consider also defining @validation on
   ttp:profile, in addition to (override) tt:tt [recorded in

   <trackbot> Created ACTION-232 - Consider also defining
   @validation on ttp:profile, in addition to (override) tt:tt [on
   Glenn Adams - due 2013-11-18].

   nigel: also we need to consider the validation scope - all
   profiles or per profile?

   glenn: may need a validation 'none' on per profile validation
   to override

   pal: what is the use case for requiring the processor to abort
   or not upon failing validation of a document?

   glenn: we have two categories: transformation and presentation.
   Transformation processing is more likely to occur in a
   ... a validation node may be required, to cause TTML to be
   removed from the pipeline on failure.
   ... Let's say a document is edited, e.g. features are added or
   subtracted, perhaps invalidating it. If I'm an author and am
   paranoid about ensuring profile compliance I may want to
   specify validation abort

   nigel: from a bbc perspective this is the sort of thing we'd
   like to do.

   glenn: from a verifier tool it's very useful for the content to
   specify behaviour.

   pal: the delta between the proposal in the powerpoint as
   Content Profile Proposal (1) (2) and (3) is:

   <glenn> PROPOSED RESOLUTION: to adopt Content Profile Proposal
   (1-3) plus: (1) extend ttp:{profile,contentProfile} to take
   list of designators; (2) allow use of @verification* on
   ttp:profile; pending decision by DEC5

   <glenn> no objections

   group breaks for coffee

   Plan to recommence at 11:15 china time, i.e. 7 minutes...

   invite zakim

   trackbot, this is ttml

   <trackbot> Sorry, nigel, I don't understand 'trackbot, this is
   ttml'. Please refer to
   <[12]http://www.w3.org/2005/06/tracker/irc> for help.

     [12] http://www.w3.org/2005/06/tracker/irc%3E

   we've hung up the phone, will redial soon

   <glenn> trackbot, start meeting

   <trackbot> Meeting: Timed Text Working Group Teleconference

   <trackbot> Date: 11 November 2013

profiles (continued)


   <trackbot> issue-206 -- Add ttp:profileCombination parameter --


     [13] http://www.w3.org/AudioVideo/TT/tracker/issues/206


     [14] http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile



     [15] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html

   pal: what is the use case for profile combination?

   nigel: not sure of any specific use case, but useful in the
   TTML -> IMSC -> xyz scenario

   glenn: this allows collisions between profiles to be resolved
   more clearly
   ... as an implementor this allows parameterisation of the
   behaviour better
   ... it's possible that we may introduce this now and find that
   nobody uses it so we then remove it.

   pal: argument against adding it now is the profile section of
   the specification is already confusing for DECE and EBU.
   ... By adding features we may make it more complex and
   introduce errors.

   glenn: much of the confusion re profiles comes from

   nigel: suggests we have the possibility of restructuring the
   documentation to add clarity

   glenn: tech specs are not user guides. The spec should say the
   minimum that makes it semantically clear.

   pal: agrees with that perspective

   glenn: in favour of editorial changes to help readers. The
   driving factor is whether to use hidden parameters or make them
   ... the combination methods right now are hidden parameters
   encoded in prose.
   ... When we go through the TTML2 spec process, if there are no
   implementations we may end up labelling features as at risk and
   then removing them.
   ... It's easier to take things out than put things in. Like to
   err on the side of putting in, if logically sound.

   mark: customer feedback from target of the spec is 'confused'
   so would be cautious about saying 'wrong assumptions' but to
   address this in a customer-oriented way.

   pal: open to see the output of the editing, which may be
   clearer after refactoring than TTML1. Would hate it to get

   glenn: agree with the principle of not adding complexity for
   its own sake
   ... should we draft a proposal as per previously discussed

   nigel: yes

   <glenn> PROPOSED RESOLUTION: to adopt Content Profile
   combination proposals, subject to the DEC5 review period

   glenn: Feature relation proposal
   ... example is #markerMode, #markerMode-continuous,
   ... could use the @restricts attribute to relate the smaller
   features to the larger features.
   ... @extends allows extension features to extend existing ones.
   ... It would be useful to think about this when reviewing e.g.
   IMSC to identify candidate features.

   pal: have done this and have not found any.
   ... profiles can not define new features, only extensions. Can
   profiles express a restriction on TTML?

   glenn: if a profile defines an extension and says it restricts
   an existing feature it can be expressed. Is that the right

   pal: so when you capture that you'd put it both in the spec and
   the profile definition?

   glenn: yes.

   pal: where would you specify it in the profile specification
   (the content profile)?

   glenn: to reuse the feature definitions in the context of
   content profiles is to add text describing their meaning in a
   content profile.

   pal: assume we do that.

   glenn: if you're in a content profile definition document, this
   allows enumeration of features that must/may/may not be present
   in the document.

   pal: so you get to the feature that's restricted - how do you
   declare that?

   <pal> <feature value="required"


     [16] http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region

   glenn: you'd need to define a feature that is the complement of
   the portion that is the restriction and then say use of the
   complement is prohibited.

   pal: intention is to say that the extent is restricted, but a
   processor that supports unrestricted extent can still go ahead,
   even if it doesn't know about the extension feature designation
   ... idea is to express still within the feature element.

   glenn: we're talking about this in the context of a content

   <pal> <feature value="allowed"


     [17] http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region

   glenn: so required means it must be present. What you're really
   trying to say is that something is permitted.

   <pal> <feature value="optional"


     [18] http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region

   glenn: this is therefore a no-op for any verifier.
   ... what you're trying to do is to prohibit a document from
   expressing a value that goes out of the document.
   ... from the validation perspective optional doesn't help.
   Suggest we take this offline and see if we can resolve it.

   pal: can't see the value of this for IMSC

   nigel: @restricts and @extends have almost opposite meanings
   dependent on whether they're processor or content profile
   ... can we come up with different labels that don't have the
   same connotations?

   glenn: we can try to come up with better terms.

   pal: was just trying to understand the intent.

   glenn: raises the issue of what do content profiles mean? Is it
   just for validation tools, or something that will be used.
   ... when you get to the presentation processor its too late in
   most cases to do anything about it.
   ... happy to think further about this last proposal and table
   it subject to further discussion.

   <glenn> sense of the room: table feature relation proposal
   subject to further offline discussion

   will break for lunch now, return at 1:30

   trackbot, start meeting

   <trackbot> Meeting: Timed Text Working Group Teleconference

   <trackbot> Date: 11 November 2013

   <pal> @plh zakim seems to have no records of ttml meeting

   <plh> we could create an ad-hoc call instead

   <plh> that would do the trick for now

   <plh> ok?

   <glenn> yes

   <plh> if I was correct, the room should be connected now

   yes it is

   <plh> the others should use this password

   <scribe> chair: nigel

   <scribe> scribeNick: pal

   <scribe> agenda: ISSUE-285

   nigel: mulitrowAlign is intended to allow the author to specify
   alignement relative to the longest lign of a <p> without a
   priori knowledge of line length
   ... would CSS flex box work

   glenn: suggest creating an example based on CSS
   ... unless there is a mapping to CSS, a feature will likely be
   ignored by OWP
   ... mapping to svg is a potential, but higher cost

   <scribe> ACTION: glenn to reach out to CSS WG to understand
   potential mappinp of multiRowAlign to CSS [recorded in

   <trackbot> Created ACTION-233 - Reach out to css wg to
   understand potential mappinp of multirowalign to css [on Glenn
   Adams - due 2013-11-18].


   <trackbot> ISSUE-286 -- Extend the background area behind
   rendered text to improve readability -- open


     [20] http://www.w3.org/AudioVideo/TT/tracker/issues/286

   nigel: adding padding at end of row improves legibility

   glenn: CSS folks mentioned box-decoration-break as a possibiliy

   ACTIOM: glenn to explore box-decoration-break in response to

   <scribe> ACTION: glenn to explore box-decoration-break in
   response to ISSUE-286 [recorded in

   <trackbot> Created ACTION-234 - Explore box-decoration-break in
   response to issue-286 [on Glenn Adams - due 2013-11-18].

   glenn: <br> and white space as an alternative

   nigel: undesirable since it mixes semantics and presentation

   ISSUE-286: CSS folks mentioned box-decoration-break as a

   <trackbot> Notes added to ISSUE-286 Extend the background area
   behind rendered text to improve readability.


   <trackbot> ISSUE-294 -- Style attribute to prevent overflow by
   shrinking text to fit on a line -- raised


     [22] http://www.w3.org/AudioVideo/TT/tracker/issues/294

   nigel: "shrink-text-to-fit" is optimal option to ensure that
   all text shows up
   ... "shrink-text-to-fit" is dormant issue in CSS

   pal: all 3 options: dl fonts, "shrink-text-to-fit" and
   reference fonts are not mutually exclusive

   nigel: should TTML 2 support downloadable fonts

   glenn: font height > font width usually so worse case line
   width can be estimated
   ... it would be good to explore downloadable fonts
   ... CSS alows a URL to be associated with combination of font
   family and style
   ... TTML 1 did not allow document to reference external

   <glenn> @font-face { font-family: FooBar; src:
   url('[23]http://fonts.org/foobar.woff'); }

     [23] http://fonts.org/foobar.woff');

   <glenn> <p tts:fontFamily="FooBar">foo bar baz</p>

   PROPOSAL: add support for downloadable fonts in TTML 2

   <nigel> issue-273

   <trackbot> issue-273 -- Map fontFamily to external font file
   resources -- open


     [24] http://www.w3.org/AudioVideo/TT/tracker/issues/273

   ISSUE-273: TPAC 2013 PROPOSAL: add support for downloadable
   fonts in TTML 2

   <trackbot> Notes added to ISSUE-273 Map fontFamily to external
   font file resources.

   pal: not implementations will support downloadable fonts
   ... so downloadable fonts is not magic bullet therefore

   nigel: add margins and reference fonts to delivery specs
   ... specify end-of-line allowance and reference fonts to
   delivery specs

   <nigel> nigel: (not in TTML2 - adding safety allowances is a
   specification issue for clients commissioning subtitle

   pal: different implementations will render the same font file
   ... authors should use <br>

   ISSUE-283: TPAC 2013 PROPOSAL: add informative text (e.g. to
   Section 9.4) on controlling line breaks (see also issue-273 on
   downloadable fonts)

   <trackbot> Notes added to ISSUE-283 Deterministic text wrapping
   and presentation.

   <nigel> Breaking for 30 mins


   <trackbot> ISSUE-288 -- Rules for splitting and accumulating
   documents -- open


     [25] http://www.w3.org/AudioVideo/TT/tracker/issues/288

   nigel: presented EBU input document.

   <scribe> ACTION: nigel to post EBU input document re: ISSUE-288
   [recorded in

   <trackbot> Created ACTION-235 - Post ebu input document re:
   issue-288 [on Nigel Megitt - due 2013-11-18].

   glenn: splitting and accumulating document should probably be
   in a separate document


   <trackbot> ISSUE-270 -- Appendix N assumption that root
   temporal extent corresponds with the beginning of a related
   media object -- open


     [27] http://www.w3.org/AudioVideo/TT/tracker/issues/270

   <scribe> ACTION: glenn to review consistent use of "Root
   Temporal Extent" in both TTML 2 and TTML 1 SE [recorded in

   <trackbot> Created ACTION-236 - Review consistent use of "root
   temporal extent" in both ttml 2 and ttml 1 se [on Glenn Adams -
   due 2013-11-18].

   ACTION-236: See ISSUE-270

   <trackbot> Notes added to ACTION-236 Review consistent use of
   "root temporal extent" in both ttml 2 and ttml 1 se.

   <nigel> chair: pal

   <nigel> scribeNick: nigel



   <trackbot> issue-296 -- Remove xml:lang placement restrictions
   from IMSC -- raised


     [29] http://www.w3.org/AudioVideo/TT/tracker/issues/296

   plh, is richard ishida likely to be able to attend?

   <plh> I thought we said Friday

   issue-296: pal proposes removing the xml:lang constraint

   <trackbot> Notes added to issue-296 Remove xml:lang placement
   restrictions from IMSC.

   plh, I didn't think we had. If he were around soon that'd be
   handy as we're discussing IMSC

   <plh> at what time would you ike Richard to be in the room?

   <plh> ok, let me ask him

   <plh> I can't locate him at the moment :(

   glenn: opentype defines different rendering rules dependent on
   language, script and feature.
   ... language is obtained from xml:lang
   ... many fonts have different rendering rules dependent on
   language, e.g. arabic is used to express pashto, arabic and
   other languages.

   <scribe> ACTION: pal to review with CFF folk [recorded in

   <trackbot> Created ACTION-237 - Review with cff folk [on
   Pierre-Anthony Lemieux - due 2013-11-18].

   issue-296: pal removes proposal to restrict xml:lang in IMSC
   though may re-instate it depending on CFF response

   <trackbot> Notes added to issue-296 Remove xml:lang placement
   restrictions from IMSC.

   glenn: line breaking algorithms also depend on xml:lang


   <trackbot> issue-295 -- Remove code point restrictions from
   IMSC -- raised


     [31] http://www.w3.org/AudioVideo/TT/tracker/issues/295

   pal: looks like 3 separate issues.
   ... 1) Inference that IMSC limits character sets in
   ... This is a document suggestion not an implementation

   glenn: this is defined in Unicode and is not in scope of TTML
   ... some languages require not just specific fonts but also
   rendering rules that are not necessarily embedded in an
   Opentype font, e.g. Indic.
   ... W3C i18n may have a view here.

   <glenn> [32]http://www.w3.org/TR/its20/

     [32] http://www.w3.org/TR/its20/

   glenn: internationalisation work has been considered in
   separate forums both within W3C and Unicode.

   pal: this application is specific to subtitles and captions and
   may therefore be slightly different.

   issue-295: action on glenn and pierre to consult richard ishida
   - is there a baseline to reference, or an external source?

   <trackbot> Notes added to issue-295 Remove code point
   restrictions from IMSC.

   <scribe> ACTION: pal to follow up on issue-295 [recorded in

   <trackbot> Created ACTION-238 - Follow up on issue-295 [on
   Pierre-Anthony Lemieux - due 2013-11-18].


   <trackbot> action-238 -- Pierre-Anthony Lemieux to Follow up on
   issue-295 -- due 2013-11-18 -- OPEN


     [34] http://www.w3.org/AudioVideo/TT/tracker/actions/238


   <trackbot> issue-238 -- smpte:backgroundImage -- open


     [35] http://www.w3.org/AudioVideo/TT/tracker/issues/238

   nigel: this is a significant divergence from the spatially
   scalable nature of TTML independent of rendering plane

   glenn: if we implement this we'll have to add specific profile
   feature designators relating to particular image types e.g.
   JPEG etc.
   ... and we'll need to add wording relating to usage, similar to
   UAX14 line breaking wording - i.e. if needed do it like this.
   ... we should use a CSS-like syntax.

   issue-238: proposal is to add functionality equivalent to smpte
   backgroundImage and define profile feature designators for
   baseline feature and image format types. Also describe usage

   <trackbot> Notes added to issue-238 smpte:backgroundImage.


   <trackbot> issue-179 -- Interpreting the pixel measure -- open


     [36] http://www.w3.org/AudioVideo/TT/tracker/issues/179

   nigel: it's problematic to relate pixels to related media
   objects as there may be none or multiple with different

   glenn: there's an even bigger problem in that the existing
   definition of pixels doesn't relate to media objects at all.
   ... it's defined via TTML 1 8.3.9 as per XSL 1.1 5.9.13 which
   uses the same language as CSS
   ... there's been some work in CSS on units and measures


     [37] http://dev.w3.org/csswg/css-values/#absolute-lengths

   glenn: we could state that pixels define a logical coordinate
   space with a mapping into device coordinates
   ... we could define a mechanism for defining that
   ... In SVG there's a viewbox attribute that defines the

   nigel: MPEG states that the track header box in BMFF should
   have the same resolution as the root extent

   glenn: wants time to craft a proposed response. Thinking about
   using the SVG model of logical coordinate space.
   ... When we define an extent on the root now that effectively
   defines a viewbox already so the change may be simple.
   ... There's extra on SVG in terms of mapping to aspect ratio
   ... we can say if you use pixels and define extent then it
   means X and if you use pixels without defining extent then it
   means Y.
   ... and make a strong recommendation.

Summary of Action Items

   [NEW] ACTION: glenn to consider also defining @validation on
   ttp:profile, in addition to (override) tt:tt [recorded in
   [NEW] ACTION: glenn to explore box-decoration-break in response
   to ISSUE-286 [recorded in
   [NEW] ACTION: glenn to reach out to CSS WG to understand
   potential mappinp of multiRowAlign to CSS [recorded in
   [NEW] ACTION: glenn to review consistent use of "Root Temporal
   Extent" in both TTML 2 and TTML 1 SE [recorded in
   [NEW] ACTION: nigel to post EBU input document re: ISSUE-288
   [recorded in
   [NEW] ACTION: pal to follow up on issue-295 [recorded in
   [NEW] ACTION: pal to review with CFF folk [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [45]scribe.perl version
    1.138 ([46]CVS log)
    $Date: 2013-11-11 10:17:03 $

     [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [46] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [47]http://dev.w3.org/cvsweb/~checkout~/2002/


     [47] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/tt:root/tt:tt/ in the presentation
Succeeded: s/issue-288/issue-270/
Succeeded: s/nigel/glenn/
Succeeded: s/issue-270/issue-288/
Succeeded: s/opentext/opentype/
Found ScribeNick: nigel
Found ScribeNick: pal
Found ScribeNick: nigel
Inferring Scribes: nigel, pal
Scribes: nigel, pal
ScribeNicks: nigel, pal

WARNING: Replacing list of attendees.
Old list: +1.617.766.aaaa Taishan
New list: Taishan [Adobe]

WARNING: Replacing list of attendees.
Old list: Taishan [Adobe]
New list: Taishan

Default Present: Taishan
Present: Taishan

WARNING: Fewer than 3 people found for Present list!

Found Date: 11 Nov 2013
Guessing minutes URL: [48]http://www.w3.org/2013/11/11-tt-minutes.html
People with action items: glenn nigel pal

     [48] http://www.w3.org/2013/11/11-tt-minutes.html

   End of [49]scribe.perl diagnostic output]

     [49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm



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 Thursday, 21 November 2013 16:28:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:24 UTC