Suresh and all,
I should have signed for both Arnoud and myself - we created the response
together, but I forgot to add his name to my standard signature. Apologies for
that oversight!
Guido
-----Original Message-----
From: Guido Gybels
Sent: 30 November 2007 12:24
To: 'Suresh Krishnan'; General Area Review Team;
arnoud(_at_)realtimetext(_dot_)org
Cc: sipping-chairs(_at_)tools(_dot_)ietf(_dot_)org;
sipping-ads(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: RE: Gen-ART review of draft-ietf-sipping-toip-08.txt
Dear Suresh,
Thanks for your constructive and helpful comments as part of your review of
draft-ietf-sipping-toip-08.txt.
Please find below the clarifications you are asking for.
<<* The term modality is used in the document but it has not been defined.
The meaning I perceive from this document does not match with the normal
English usage of "modality". I think the document uses this word to
describe the way in which the TOIP device interacts with human. This
needs to be clearly stated.>>
Modality is a common term in standardisation and multimedia applications, which
refers to the mode of communication ("text", "voice", "video"). In a broader
definition, it refers to the senses (hearing, vision, etc):
http://dictionary.reference.com/browse/modality
As such, I think modality is used in both a normal English sense as well as
being the established term used to refer to the various modes of communication
(or media types) in standards and other technical documents.
<<* I do not have strong feelings regarding this, but I feel that using
RFC2119 terminology in this document is inappropriate given that the
document is aiming to be an Informational RFC.>>
We think it is quite important to use the RFC2119 wording, even more so because
the ToIP framework addresses implementations that are intended, in addition to
mainstream use, for specific user groups such as deaf people. Mainstream
implementers have often little detailed understanding of the specific needs of
such user groups. Using the RFC2119 terminology makes it much simpler and
clearer what are the absolute essentials and what are the optional or nice to
have features of a solution that aims to meet these users needs. The use of the
RFC2119 termonology removes ambiguity.
<<* Section 5.2.1: I think requirement R5 is redundant given requirement
R6. Is there any use case that is covered by R5 and not by R6?>>
They are different requirements. R5 contrasts a ToIP-centred application with a
more traditional total conversation or VoIP implementation. Most SIP based
conversational implementations will fall back to audio-only when bandwidth
constraints prevent a total conversation session to be set up. That is in line
with the fact that most people see such applications as richer "telephony"
applications, and hence voice is seen as the logical fall-bakc modality.
However, for deaf and hard of hearing people that does not work. So, for a ToIP
application, even if it allows other media types (and indeed many hard of
hearing people for example will prefer to talk to the other party, but to
receive text back), it should fall back to text - which is what R5 expresses.
R6 is different - it does not deal with low bandwidth fall-back, rather with
user preferences. There is no network problem with
low bandwidth etc. This requirement is given because, again, many users will
set a preference for audio. Real-time text is not what they would select by
default. Except if you are deaf or hard of hearing. If there is no real-time
text in the call, the user with the hearing loss cannot continue the call.
<<* Section 5.2.2: Why is there a requirement for maximum delay per
character? A character by itself is not useful. I would think setting
the delay per word makes more sense, since this is the smallest
comprehensible text unit.>>
Yes, this is a classic misunderstanding. To achieve a real-time experience, it
is essential that text is transmitted as soon as it is generated. This makes it
the text equivalent of what real-time voice is to other users. A more detailed
explanation of RTT can be found here:
http://www.ictrnid.org.uk/whyrtt.html
RTT is, emphatically, not word or line buffered. Especially with relay
operators in a call, it's important for characters to be sent immediately -
which helps the operator anticipate and streamlines the conversation.
As ToIP is supposed to provide an IP based implementation of RTT, it is
essential that it is equivalent to other RTT applications in this respect. Also
note that in some languages there is a lot more semantic content associated
with a single "character".
<<* Section 5.2.4: I am not clear what this requirement means. Can we add
more specific text to this one.
"R31: Users MUST be presented with appropriate session progress
information at all times.">>
In voice telephony, users are given audible feedback as to the state of the
connection (i.e. a dial tone, a ringing tone, a busy tone). Deaf and hard of
hearing people that cannot hear such audible information should be presented
with equivalent session progress information in a mode that meets their needs
(i.e. is appropriate for them). Similarly, such information must not just be
presented in audible format - a blind or partially sighted person would need a
different representation. Nevertheless, there is a requirement that the session
state and progress information is being provided to the user, so that they are
left in no uncertainty as to what the state of the session is.
<<* Section 5.2.4: I think this requirement has enormous privacy
implications. This needs to be explicitly stated.
"R35: It SHOULD be possible to save the text portion of a conversation.">>
This is no different from a voice phone where you can record and save the
conversation, something that must telephones with built-in answering machine
can do, or indeed something that a lot of off-the-shelf mobile phones allow you
to do. Traditionally, PSTN textphones in most cases allow users to store and/or
print the conversation and a ToIP version of text telephony should really be
equivalent. The privacy aspects of this are really an issue of local law, and
can differ quite a bit from country to country. By making this a "SHOULD"
requirement, we recognise the possibility that some implementations could not
allow for this, or could indeed allow for example a network administrator to
disable such feature.
In some countries, the party that intends to save the conversation might be
expected to tell the other party about this, but again that is really a matter
of legal responsibilities.
Thanks, Suresh, for your comments - I hope the above helps to clarify the
issues you raised. Do not feel to contact us if you have any further questions.
Best wishes,
Guido
Guido Gybels
Director of New Technologies
RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20 7294 3713
Fax +44(0)20 7296 8069
Txt +44(0)20 7296 8001 Ext 3713
http://www.rnid.org.uk/
http://www.ictrnid.org.uk/
++Extra message.
Get your Christmas cards from us - visit www.rnid.org.uk/christmas
[Extra message ends].
++Disclaimer.
This email and attachments (if any) must be swept for viruses before opening.
Their contents may be confidential or privileged and are intended solely for
the named recipient. If you are not the intended recipient and you have
received this email in error, you must not read or use this email and should
notify RNID on telephone or textphone 020 7296 8282.
[Disclaimer ends].
++Company information.
The Royal National Institute for Deaf People. Registered Address 19 - 23
Featherstone Street, London EC1Y 8SL. Registered charity Number 207720. A
company limited by guarantee in England and Wales Number 454169.
[Company information ends].
[End]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf