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@xxxxxxxxxxxxxxxx
Cc: sipping-chairs@xxxxxxxxxxxxxx; sipping-ads@xxxxxxxxxxxxxx;
ietf@xxxxxxxx
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf