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

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 23 Mar 2006 07:26:38 -0500

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
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