Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)
RFC 5194

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

(Jari Arkko) (was Discuss) Yes

Comment (2007-12-17)
No email
send info
IESG writeup is empty or missing. Please fill in.

(Jon Peterson) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) (was No Record, No Objection) No Objection

(Russ Housley) (was Discuss) No Objection

(Chris Newman) No Objection

Comment (2007-12-20 for -)
No email
send info
I support Jari's discuss but trust him to hold it for resolution.

The document makes a lot of recommendations (45) and while many are
excellent, I'm dubious they'll all be followed in practice.  I commend
the authors for considering user interface issues seriously in the
requirements.  The IETF has a track record of under-specifying
user-interface considerations and that has resulted in less successful
protocols.  However, some of those should perhaps be treated as
"considerations" rather than requirements.

The acronym expansion for "UTF-8" is incorrect.  It should be:
 UCS/Unicode Transformation Format

This requirement:
   R13: A ToIP service MUST be able to deal with international character
  sets.
is incorrectly worded as only one character set is mandated (Unicode).
One possible re-wording would be "A ToIP service MUST comply with the character set policy in RFC 2277."  But other approaches also work.

An informative reference to draft-klensin-net-utf8 may pick up some
issues with interoperability and text canonicalization that may not
be covered in ITU-T T.140.  However, as I haven't read ITU-T T.140
I can't say how consistent the other advice would be.

(Tim Polk) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Comment (2007-12-19 for -)
No email
send info
I agree w/ Cullen but, will let him hold the discuss.

Magnus Westerlund No Objection

(Cullen Jennings) (was Discuss) Abstain

Comment (2008-03-17 for -)
No email
send info
I don't think this document should describe itself as a framework - it has lots of requirements many of which I think are excellent, but it is lacking something that could be considered a complete frameworks for real time text. It makes recommendations well outside the scope of the sipping charter - many of which I doubt more than a very small handful of people have read. I'll poke on section 6.2.4.4 as one specific example.