Subject: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t xt

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 1 Jul 2006 08:30:09 -0400

Hi, Mary:
 
As indicated, I am enclosing my comments in the enclosed paper.
 
I appreciate your lead in this respect.
 
Best regards,
Radhika
 
_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Sat, 1 Jul 2006 22:40:32 -0700

As an RAI AD, this has me very concerned and defintely has my  
attention. Jon is the responsible AD for this WG but this hits on  
some topics that I would hope we can have some level of consistency  
on in the RAI area. It's a really busy time due to holiday and travel  
schedules not to mention the IETF work. I know there is some history  
on all this and I need to get back up to speed on the issues.

Please give the ADs and Chairs a little time to talk about this and  
figure out some of the issues.

Thanks, Cullen <with my AD hat on>

On Jul 1, 2006, at 5:30 AM, Roy, Radhika R. wrote:

> <Comments on ToIP 30-June-06.doc>
> <mime-attachment.txt>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 2 Jul 2006 16:32:27 +0100

Mary,

Radhika brings up some questions and want you to make the decisions.
Below are my comments and advice as a co-contributor, numbered as Radhika´s
comments:

2.1 and 2.2. The term real-time text
------------------------------------

There were unimportant historical reasons to use "interactive" and
"conversational".
I have not perceived the very strict distinction between "text" and
"real-time text" as Radhika´s comments indicate. But I am happy to be
consistent and use the term wherever it is suitable.
I thought it did not read well with "real-time text relay service" when in
practice in real world it is called "text relay" since long.

My advice: Accept to use the term "real-time text" in the places indicated.

2.3 The timing requirements on real-time text
---------------------------------------------
This comment is not correct. The delay requirements on real-time text are
less stringent than on audio and video. The bad effects of not meeting the
requirements are similar for all media but the timing values are different.

For audio and video the delay is noticable but not annoying at 400 ms.
For real-time text the same situation is seen with 1 s delay.

For audio and video the delay is annoying, but the connection can still be
used at 800 ms delay.
For real-time text the same user experience is seen at 2 s delay.

At higher delay figures turntaking collissions appears and makes the
conversational situation very disturbing. Users are able to adapt and
introduce procedures that make it possible but inefficient.

The values for text are documented in ITU-T F.700 [25]

The original text is good.

Advice: Do not accept.

2.4 Indication of loss
----------------------
R14: Where it is possible, loss of real-time text during transport should be
detected and the user should be informed.

The comment Proposes the addition:

 "Like conversational audio, if some algorithms are used to recreate the
lost real-time text, the users must be informed what has been recreated."

My advice: Do not accept.
An indication of loss is only needed in the cases when it was impossible to
recreate the character. The user does not bother if the character was
received in its original transmission or by a recovery scheme, but it is
quite important to get a mark in a place where something really have been
lost.

2.5 Include mainstream users in users of alternative alerting
--------------------------------------------------------------
The comment proposes to add a phrase in R25:

R25: User Agents for ToIP services MUST have alerting methods (e.g., for
incoming sessions) that can be used by deaf and hard of hearing people and
the main stream normal users who cannot use audio communications because of
safety or other reasons or provide a range of alternative, but equivalent,
alerting methods that can be selected by all users, regardless of their
abilities.

Do never accept this way of using the word "normal" to distinguish from
people with disabilities. It is politically incorrect.
I think mainstream is OK but on the limit.
Furthermore "all users, regardless of their abilities" was already there
later in the sentence so the addition just complicates the sentence.

Advice: Do not accept the proposal.

2.6 Introduce QOS requirements
----------------------------------
The comment proposes this addition:
Rxx: Like conversational audio, real-time text SHALL be provided the same
level of Quality-of-Services (QOS) over all networks (e.g., Wire-line and
Wireless LAN, Cellular Network, IP) to meet the real-time application
performances.

The idea is right, but the requirements are different. Real-time text can
accept longer delays and more jitter. It is very important that it is not
downprioritized in a congestion situation compared to audio.

Advice: accept the idea, but change the words. I have no proposal.

2.7 Mobility

OK, accept addition of WLAN

3. Editor

For me it is OK as it is. No change needed. All earlier authors are either
editors or contributors now, and the IETF procedures explain that that has
equal value. In most other standardisation bodies the authors are not even
mentioned in the final depersonalised product. In IETF we maintain the
names, and that is good for finding the track back to experts in the area.
But why put so much effort in discussion of who are mentioned as editors?
For me the important thing is to get a document out there approved and ready
to be used for harmonisation and better communication functionality for all.
Can you, Radhika please think in such directions and accept the current
distribution of editors and contributors? That would ease the progress of
the document and be of benefit for all.

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Ursprungligt meddelande-----
Från: Roy, Radhika R. [mailto:[email-masked]]
Skickat: den 1 juli 2006 13:30
Till: Mary Barnes
Kopia: [email-masked]
Ämne: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Hi, Mary:

Best regards,
Radhika