Re: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-ttml-03: (with COMMENT)

[James Sandford <[e-mail]>]

Hello,
I'm updating the I-D to address these (and other) comments. I'm unsure what isn't meant by the last item, though. "I might include a short note that the text contents are meant to be interpreted by a human, and content from untrusted sources should be viewed with appropriate levels of skepticism". Surely this applies to any media carried over RTP? Or at least any which may be rendered for a human audience.

Regards,
James

==========
James Sandford
R&D Project Engineer

BBC Research and Development
5th Floor
Dock House
MediaCityUK
Salford
M50 2LH

Tel: 030304 (09549)
Web: http://www.bbc.co.uk/rd

________________________________________
From: Benjamin Kaduk via Datatracker [[e-mail]]
Sent: 17 October 2019 03:23
To: The IESG
Cc: [e-mail]; Roni Even; [e-mail]; [e-mail]; [e-mail]
Subject: Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-ttml-03: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-payload-rtp-ttml-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this clear and well-written document!

Section 2

   The term "word" refers to byte aligned or 32-bit aligned words of
   data in a computing sense and not to refer to linguistic words that
   might appear in the transported text.

Either of byte-aligned and 4-byte-aligned, as opposed to aligned to one
of those and in multiples of the other in length?

Section 4

I find myself feeling like I would benefit from a brief discussion of
the relationship between documents and the RTP stream before getting
into the details of the payload format (e.g., "one document per
subtitle", "many documents per stream but each document contains some
minutes of data", or "totally up to the profile in use").  Even having
finished the I-D I'm still wondering: it's clear that we only have
a single TTLM stream in a given RTP stream, and a given RTP packet has
(part of) a TTML document in the epoch of the timestamp of the RTP
packet, and I can only have one document active at a time.  On the
flip side, different documents must belong to different epochs.  So it
seems that I could either make large documents stuck on a single
timestamp, or small documents with (relatively) rapidly advancing
timestamps, regardless of how I need to actually split the TTML content
into packets in order to meet MTU requirements (and possibly packet
pacing ones).  Given that this is RTP and we're used to ignoring things
with old timestamps, I mostly expect the latter to be more common, but
would appreciate some guidance in the document [sic].  This seems to
roughly be Adam's third Discuss point.

Section 4.2.1.2

   If the TTML document payload is assessed to be invalid then it MUST
   be discarded.  When processing a valid document, the following
   requirements apply.

Does this imply that I have to wait for the entire document to arrive
before I start processing it?

   Each TTML document becomes active at the epoch E.  E MUST be set to

nit: I suggest s/the/its/, since there is not a global distinguished
epoch.

Most of the security considerations I can think of apply more to the
TTML format itself rather than the RTP payload.  I might include a short
note that the text contents are meant to be interpreted by a human, and
content from untrusted sources should be viewed with appropriate levels
of skepticism.