Subject: RE: [Sipping] Comments on draft-ietf-sipping-toip-04.txt

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 23 Mar 2006 07:46:10 -0500

Hi, Tom and all:
 
It is great that Tom has taken time to review the document. It would be
superb if more people like him review the document and provide comments.
 
In addition, I have provided my comments, and Gunnar has volunteered to take
care of those with the collaboration of the WG members.
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Tom-PT Taylor
Sent: Thu 3/23/2006 7:26 AM
To: Sipping (E-mail)
Cc: [email-masked]
Subject: [Sipping] Comments on draft-ietf-sipping-toip-04.txt

I volunteered to review the subject draft during the meeting yesterday.
I find the draft reasonably well structured, but I have a large number
of editorial suggestions which will be mostly moot if what I am about to
suggest is accepted. Leaving these aside, I have also identified some
substantive issues. The key issue is that of the proper scope of the
document.

It is clear that the intent of the editor was that this be a system
specification for text-on-IP systems. With that in mind, I looked for a
precedent for such a document in the IETF archives. The first thing that
came to mind was RFCs 1122 and 1123, "Host Requirements". However, these
documents really consist a suite of protocol profiles.
draft-ietf-sipping-toip-04.txt covers a range of issues, only some of
them relating to protocols.

Searching the RFC database using the term "system specification", I came
across RFC 1297, "NOC Trouble Ticket Requirements". Compared with RFC
1297, the subject draft is very protocol-oriented. On the other hand,
RFC 1297 is concerned with running the network, while the present draft
is about a network application. So I'm not sure that RFC 1297 is a
suitable precedent as an indicator of the extent of IETF interest in
defining application systems.

My gut feeling is that the present scope of the document is suitable to
an organization like the TIA or the ITU-T. On the other hand, an
applicability statement describing the use of SIP, SDP, and specific RTP
payload types to support ToIP would lie squarely within the IETF's
sphere of interest. In fact, I believe there are a few requirements for
new SDP attributes buried in here, and further examination might reveal
new SIP requirements too. I therefore believe it is in the interest of
the WG to extract an applicability statement from the current content of
the draft.

If the WG chooses to accept the current intent of the draft, I have a
number of substantive comments which should be fairly easily addressed.
I record them below so they won't be lost, but the question of scope
should be dealt with before people read further.

---------------------------

1. In the definition of transcoding service in section 4, I have a
feeling the editor meant transcoding to apply especially to conversions
between different media types. Could this be confirmed?

2. Requirement R4 in section 5.2.1 currently reads:

"R4: Systems SHOULD allow the user to specify a preferred mode of
    communication, with the ability to fall back to alternatives that the
    user has indicated are acceptable."

The introduction to 5.2.1 talks about people who are constrained to one
media type in one direction and a different one in the other. It seems
that this directionality should be captured in R4 by adding the words
"in each direction" after "communication" at the start of the second line.

3. Requirement R5 immediately following gives two reasons why the system
may be unable to provide simultaneous real-time text and voice: lack of
system capability and network constraints. It then goes on to require
best-effort establishment of communication. I suspect this best effort
was meant to apply to the network-limited case only. If this is the
intention, the words "either because the system only supports alternate
modalities or" -- that is, the case of lack of system capability --
should be deleted from the requirement.

If something else was intended, it must be better spelled out. One can't
quite visualize how a system not designed to do something will go about
making a best effort to do it anyway.

4. Requirement R8 seems to be a special case of requirements R1 and
perhaps R2. As such it is redundant and should be removed.

5. Requirement R9 is missing capitalization of MUST and RECOMMENDED.
Further to that, in terms of protocol requirements the ability to
specify the sign language should be a MUST, even if it is only
RECOMMENDED for system implementation. This strikes me as a need for a
new SDP attribute.

6. I wasn't sure whether the ability to support international character
sets was a set-up issue (section 5.2.1) or a transport issue (its
current section, 5.2.2). I think I see the argument for its current
placement, but the editor may wish to comment.

7. Requirement R15 as written is circular: "Where possible, it must be
possible ...".  It sounds like the intention was to say that it SHOULD
be possible to send and receive real-time text simultaneously.

8. R19 in section 5.2.3 reads as follows:

"R19: Adding or removing a relay service MUST be possible without
    disrupting the current session."

I'm a little unclear what is meant by this requirement. Adding or
removing a relay station is definitely going to disrupt some media flows
within the session. The modality of communication between the
participants will change, in general. I suspect the requirement means to
say that
(1) communication between the end participants should continue after the
addition or removal of the relay service, and
(2) the effect of the change should be limited in the users' perception
to the direct effect of having or not having the trnscoding service in
the connection.

I will do more work on the document when the WG makes its decision on
the scope.

Tom Taylor

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
<https://www1.ietf.org/mailman/listinfo/sipping> 
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Colin Perkins <[email-masked]>
Date: Wed, 29 Mar 2006 13:30:50 +0100

Hi,

> superb if more people like him review the document and provide  

Tom's concerns regarding scope seem well-founded to me. The present  
draft seems to confuse system definition with protocol requirements  
and applicability. The latter are clearly in scope, but it's not  
clear that the IETF is the right place to define the former.

Colin