Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)
Note: This ballot was opened for revision 09 and is now closed.
(Jari Arkko) (was Discuss) Yes
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 value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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 22.214.171.124 as one specific example.