Testable requirements to replace clause 6.2.1.1 in EN 301 549 v.3.1.1
Based on some of the ideas introduced in Issue #234, the following proposal attempts to:
- maintain a similar multi-requirement sub-division of the 6.2.1.1.x introduced into the tests of Issue #234
- eliminate having multiple tests associated with a single requirement, which breaks the underlying EN 301 549 principle of having a 1:1 correspondence between requirements and tests where, if a test is passed the corresponding requirement is met. Having multiple tests for one requirement undermines this simple model.
- making sure that what is tested directly corresponds to what appears in the requirement, by defining a term "basic RTT"
- avoid the need to specify pre-conditions on tests that attempt to ensure that the failure of a test will be the responsibility of the provider of the ICT being evaluated. All attempts to control all potential causes of a test failure that are outside the responsibility of the provider of the ICT under test will be burdensome to whoever is doing the testing and will always fail to provide the necessary isolation of responsibility
- takes the original 6.2.1.1 and, with small re-writes, transforms it from a requirement that could never be satisfactorily tested, to a recommendation ("should") that captures the overall intent of what is required for fully interoperable RTT services.
In each of the 6.2.1.1.x tests described in Issue #234 there is a multi-step procedure that involves the typing and receiving of characters as being a test that the "RTT communication" referred to in the requirements is achieved. To ensure that what is tested corresponds to what is required, this multi-step procedure is summarised in a new term "basic RTT". This term defines a concept that is only relevant in the context of the requirements and tests of EN 301 549 and not intended to have any significance beyond that very specific usage. The definition is as follows:
basic RTT: text typed continuously for 10 seconds without the use of the return or send key appears at the other end of a connection whichever end originated the connection
6.2.1 RTT provision
6.2.1.1 RTT communication
Where ICT provides functionality that allows continuous bidirectional voice communication with between one two or more people,
the ICT should shall provide functionality that allows bidirectional RTT communication with those same people, except where this would require design changes to add input or output hardware to the ICT.
6.2.1.2 RTT communication between services
Where ICT is an electronic communication service,
and it supports bidirectional voice communication with one or more electronic communication services,
the ICT shall support basic RTT with the other services.
6.2.1.3 RTT communication within a service
Where ICT is an electronic communications service supporting bidirectional voice communications between ICT within the service,
the ICT shall support basic RTT between the same ICT in the service.
6.2.1.4 RTT communication with a roaming user
Where ICT is an electronic communication service, and it supports bidirectional voice communication with one or more electronic communication services,
the ICT shall support basic RTT with a user who is roaming and using a different service.
6.2.1.5 RTT communication with emergency services
Where ICT is an electronic communication service, and it supports bidirectional voice communication with emergency services,
the ICT shall support basic RTT with emergency services.
6.2.1.6 RTT communication of voice capable ICT
Where ICT supports bidirectional voice communication with other ICT within a service or directly between ICT over a network,
the ICT shall support basic RTT with the other ICT, except where this would require design changes to add input or output hardware to the ICT.
NOTE 1: There is no requirement to add: a hardware display, a hardware keyboard, or hardware to support the ability to connect to a display or keyboard, wired or wirelessly, if this hardware would not normally be provided.
NOTE 2: This requirement includes those products that do not have physical display or text entry capabilities but have the capability to connect to ICT that do have such capabilities as long as it does not require design changes to add input or output hardware to the ICT. It also includes intermediate ICT between the endpoints of the communication.
NOTE 3: This requirement applies to ICT that supports all types of real-time bidirectional voice communication between ICT, including those between people each using ICT, and a person using ICT on one end and ICT alone on the other end. For example, it would apply to a bidirectional voice conversation option on a user’s ICT that connects directly over IP to a bank, or doctor, or person, or organization even if no remuneration or use of user data etc is provided by user in exchange for using the voice option.
6.2.1.7 Concurrent voice and text
(this is the old 6.2.1.2 and there are no proposed changes to its content)
Where ICT provides a means for bidirectional voice communication and for users to communicate by RTT,
it shall allow concurrent voice and text through a single user connection.
NOTE 1: With many-party communication, as in a conference system, it is allowed (but not required or necessarily recommended) that RTT be handled in a single display field and that "turn-taking" be necessary to avoid confusion (in the same way that turn-taking is required for those presenting/talking with voice).
NOTE 2: With many-party communication, best practice is for hand-raising for voice users and RTT users to be handled in the same way, so that voice and RTT users are in the same queue.
NOTE 3: With a many-party conference system that has chat as one of its features - the RTT (like the voice) would typically be separate from the chat so that RTT use does not interfere with chat (i.e. people can be messaging in the chat field while the person is presenting/talking with RTT - in the same manner that people message using the chat feature while people are talking with voice). RTT users would then use RTT for presenting and use the Chat feature to message while others are presenting (via Voice or RTT).
NOTE 4: The availability of voice and RTT running concurrently (and separately from chat) can also allow the RTT field to support text captioning when someone is speaking (and it is therefore not being used for RTT since it is not the RTT user's turn to speak).
Unlike Issue #234, the corresponding tests that the requirement has been met will not be by means of attempting to set up a connection and test that RTT communication has been achieved, but by the availability of evidence that successful testing has "has been achieved in any manner" (to quote the language used in one of the Issue #234 C.6.2.3.x pre-conditions).
A test of 6.2.1.2, that is compatible with how all the other tests in EN 301 549 have been constructed would read:
C.6.2.1.2 RTT communication between services
Type of assessment | Declaration |
---|---|
Pre-conditions | 1. The ICT under test is an electronic communication service that supports bidirectional voice communication with one or more electronic communication services |
Procedure | 1. Check if there is documented evidence that basic RTT with another service has been achieved, whichever service originates the communication. |
Result | Pass: Check 1 is true Fail: Check 1 is false Test is not applicable, or test is not valid if pre-condition 1 is not met. |
All the other tests can follow the identical pattern of mapping the requirement pre-conditions into the test pre-conditions and the body of the requirement as the single step of the test procedure.