Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration
RFC 4612

Note: This ballot was opened for revision 05 and is now closed.

(Allison Mankin) (was Discuss, Yes, Discuss, Yes) Yes

Comment (2006-03-22)
No email
send info
ietf-types review was fine, ended today

(Harald Alvestrand) (was Discuss) No Objection

Comment (2004-01-08)
No email
send info
I think audio/t38 is a travesty. It Just Looks Silly.
Using image/t38+rtp looks much better.
But if the name is really committed to for other reasons, I won't block it.

(Steven Bellovin) No Objection

Comment (2004-01-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This sentence doesn't parse.

   For example,
   using RTP allows one to take advantage of the redundancy [11], header
   compression [12][13], and other RTP-related work within the IETF.
   Using RTP, as opposed to UDPTL, for transport provides better
   interoperability with a wider range of devices that know and
   understand RTP.

(Brian Carpenter) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-12-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Since this is a time-sensitive document in the interests of expediency I'm 
voting no-obj, but these comments really amount to a discuss. I hope they can
be adequately addressed in an RFC Editor note.

(1) The document talks about the UDPTL protocol at length and compares it with
    RTP, but does not give a reference where UDPTL is defined. In fact the
    document sort of implies that RFC 3362 contains additional information
    about this when in fact RFC 3362 does not mention UDPTL at all.

    The definitive reference for UDPTL is apparently section 8 of T.38 itself.
    (The section may have changed in the 7/03 revision of T.38, but as far as
    I can tell this revision is not yet available from the ITU and I had to
    make do with the 3/02 version.) As such, a sentence to the effect of
    "UDPTL is defined in section 8 of T.38" needs to be added. Alternately,
    if there is a better reference for UDPTL (the ITU specification of it
    appears to be complete but isn't very well written), it could be given
    instead.

(2) Unless something has changed with the ITU of late, amendments amend
    specifications rather than replacing them. This document does not contain
    a reference to T.38 itself, only to an unpublished amendment to it. I
    fail to see how this document can specify a media type based on T.38 and
    discuss a protocol defined in T.38 yet not have a normative reference to
    T.38 itself.

(3) The encoding considerations given do not specifically state that the
    content of this media type is binary. This should be done in the interests
    of consistency.

(4) The second paragraph of section 3 refers to "RTCP". I believe this should
    be "RTP".

(5) When all is said and done this document remains quite unclear as to what
    the purpose of this media type is. No doubt this is all clarified in
    the amendment to T.38 but that's not available to check. The addition of
    at least one example would really help make it clear what's going on here.

Finally, the ballot for this document arrived in email on 28-Dec-2003, along
with a note that an RFC number needs to be assigned by 31-Dec-2003. While I am
sympathetic to the need to help out other standards bodies in regards to their
publication schedules, I have to note that:

(a) Three days is nowhere near enough time in the best possible case.
(b) We're in the middle of the holidays right now, making this pretty much
    worst case timing.
(c) At least two of the specification this document critically depends on --
    the 7/03 version of T.38 and the 1/04 amendment to T.38 -- are,
    as far as I can tell, unpublished at the present time. It is simply not
    possible to do an adequate review of this specification without this
    material.

Now, I don't see what we can do about (a) or (b) other than to let failure
to get the RFC number assigned by the deadline serve as a lesson. But (c)
is another matter. When presented with a document such as this that is
intertwined with unpublished and not-publicly-available specifications
from another standards body there needs to be a way for IETF memebers to
access preliminary versions of those specifications so adequate review can be
done. I'm being nice by voting no-obj here; I doubt if I'll be so inclined
in the future.

(Ted Hardie) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2006-01-05)
No email
send info
My original discuss test:

I can't find any record of the media type registration that's described in this document being reviewed on the ietf-types list.  I'd like to talk about that given that the document status is listed as Historic, but the document says that the intended usage of the type is "Common".  Might "Obsolete" or "Limited Use" not be better choices?

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection