RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text
draft-ietf-avt-rtp-3gpp-timed-text-15

[Ballot comment]
Given that timed text may or may not be synchronized with media such as video or audio, as stated in the Introduction, it seems a little odd that the recommended SDP behavior (section 9.1) suggests that the video media type is used in the SDP m= line.

[Ballot comment]
I see informative reference:
    [18] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO
    10646", RFC 2044, October 1996.
Is that intentionally to an RFC that has been obsolted twice, first by
RFC2279 and then RFC3629 ??

I further wonder if the references to UTF8 and UTF16 should not be
normative ?? You will have to understand them if you want to implement
this spec, no?

Magnus's writeup (the Secretariat is not inserting these for us).

Please note that this document is
on the 3GPP-IETF dependency list. Please provide expedited handling of
this so that 3GPP can avoid needing to remove the functionality this
document represent from its Release 6 specifications.

    1.a) Have the chairs personally reviewed this version of the Internet

        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes, we have reviewed it and finds it ready for publication.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has been throughly reviewed by both AVT members and the
participants of ietf-types list.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

The ietf-types list review resulted in a change of media type from
text/3gpp-tt to video/3gpp-tt. This change has been discussed and
represent an good compromise from AVT perspective in the light on the
ongoing debate regarding media type usage by RTP.


    1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No

    1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

    1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)


Yes.

Secretariat not adding writeups :(
Magnus's writeup:

Please handle this document as
quickly as possible as DLNA require it as an reference in their
specification.


    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes, we have reviewed it and finds it ready for publication.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has been reviewed by AVT members

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

It hasn't been reviewed by ietf-types@iana.org. However this will be
requested at the same time as this request is submitted.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

    1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No

    1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

    1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

Yes.

Sent to Chairs and Authors:
I have one immediate question:  the normative reference for
AC3 seems inaccessible.  The ATSC website mentions it in a FAQ,
but provides a copy only of Rev A from 2001, at least that I
can find.

This is the ref I'm looking for:
[ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC
Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B,
June 2005.

The IESG has been concerned about this topic of normative spec
availablity, so let me find out what the process has been
on this one, since it's the first to have a publication request
since the new discussion arose:

  - was the WG able to consult this specification as needed?
  - if not, what was the method for evaluating the
    (normative) dependencies from it?
  - one answer may be that the authors' presentation
    material from the spec was an important resource -
    maybe IETF proceedings viewgraphs should also
    be cited normatively if the spec is not accessible.