Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)
draft-ietf-sipping-toip-09

[Ballot comment]
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.

[Ballot discuss]
This is an overall good document. I have one issue, however.

The document assumes a model where the text source is a person typing. The transport requirements reflect this. However, where we make text input possible there will be someone who will be pasting the War and Peace into the system -- either intentionally or by accident. We've seen this in instant messaging space; people find it convenient. And I've seen implementation problems around this more than once.

I would suggest that a requirement be added to deal with text input that exceeds sender, receiver, or network (congestion) capabilities. One way to deal with this is to ensure in the sending side that the sending rate does not exceed some reasonable upper limit

[Ballot discuss]
The IESG Ballot Write-up contains only the template.

  Following the Gen-ART Review and the SecDir Review, the authors
  proposed changes to the document.  These are not reflected in notes
  to the RFC Editor or an updated Internet-Draft.

[Ballot comment]
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.

[Ballot discuss]
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. I have no problem publishing it with appropriate applicability but if the WG wants this to be something that future work can be held to, or other SDOs would reference as a requirement for systems or solutions, there are some significant issues of what level of product specification the IETF is doing. I'd like to talk about options for dealing with this document then I will update this discuss to be more actionable.

[Ballot discuss]
This is an overall good document. I have one issue, however.

The document assumes a model where the text source is a person typing. The transport requirements reflect this. However, where we make text input possible there will be someone who will be pasting the War and Peace into the system -- either intentionally or by accident. We've seen this in instant messaging space; people find it convenient. And I've seen implementation problems around this more than once.

I would suggest that a requirement be added to deal with text input that exceeds sender, receiver, or network (congestion) capabilities. One way to deal with this is to ensure in the sending side that the sending rate does not exceed some reasonable upper limit. Another way would be to extend the buffering and reception requirements and make it possible to use TCP-based transport. But I understand that this might go beyond what we want to do for this particular application, so the former approach may be preferrable.

PROTO Write-up

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? Which chair is the WG
Chair Shepherd for this document?

Yes, the WG chairs have reviewed this version and believe the ID is
ready.
Mary Barnes is the WG Chair Shepherd for this document.

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 WG members, with no concerns about the
depth or breadth of the review.

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, internationalization,
XML, 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.

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 WG consensus behind this document, with adequate time for
discussion and resolution
of issues raised.

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. (It should be
separate email because this questionnaire will be entered into
the tracker).

Yes, one individual has continued to express discontent over a
non-technical issue.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.

There are two normative reference that are not yet published as RFCs:
14. G. Camarillo, "Framework for Transcoding with the Session
Initiation Protocol"
IETF May 2006 - Work in progress.
16. G. Camarillo, "The SIP Conference Bridge Transcoding Model,"
IETF, January 2006 - Work in Progress.
However, these two documents have undergone IESG review and it is
anticipated that they would be published as RFCs prior to the
publication of this document.

There are no normative references which are downward references.

------

Protocol write-up for: draft-ietf-sipping-toip-07.txt
by Mary Barnes, mary.barnes@nortel.com, 15 Sept 2006

Technical Summary

This document lists the essential requirements for real-time Text-
over-IP (ToIP) and defines a framework for implementation of all
required functions based on the Session Initiation Protocol (SIP) and
the Real-Time Transport Protocol (RTP). This includes interworking
between Text-over-IP and existing text telephony on the PSTN and
other
networks.


Working Group Summary

The SIPPING WG supports the development and advancement of this
document.

Protocol Quality

This document defines no new protocol elements. This document was
thoroughly reviewed by WG chairs and WG members. Mary Barnes is the
WG chair shepherd. Jon Peterson is the responsible Area director.