Removal of “except where this would require design changes to add input or output hardware to the ICT” from 6.2.1.1
Removal of “except where this would require design changes to add input or output hardware to the ICT” from 6.2.1.1 has been requested to avoid an unnecessary scoping of the requirement 6.2.1.1 that supports the Annex I Section IV (a)(i) requirement for provision of RTT in addition to voice communication for electronic communication services.
The request is rejected because:
-
The phrase is not introducing any restrictions with regard to services as it concerns hardware.
-
The exception is needed to ensure alignment with the EAA requirement in Annex I Section I point 2(o)iii which applies only “when such products have text capability in addition to voice”.
To emphasize the relationship with the EAA annex I(I)2(o)iii bullet point one, NOTE 3 that read:
NOTE 3: 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.
will be now rephrased as follows:
NOTE 3 For ICT that have no text generation or display capability in addition to voice, there is no requirement to change the design to include a hardware to generate and/or display text or hardware to support the ability to connect, wired or wirelessly, to another device to generate and/or display text, if these functions are not already part of the design of the ICT.
Activity
added EAA Alignment label
assigned to @agata
I removed "a" from in front of Hardware to agree with standard english
I think we should also change the last phrase
"if these functions are not already part of the design of the ICT" to
"if the hardware to support these functions is not already part of the design of the ICT".because the beginning of the sentence is about hardware - and not functions.
that would make it
NOTE 3 For ICT that have no text generation or display capability in addition to voice, there is no requirement to change the design to include hardware to generate and/or display text or hardware to support the ability to connect, wired or wirelessly, to another device to generate and/or display text, if the hardware to support these functions is not already part of the design of the ICT.
-
It looks like we are getting closure @pluke
Nominate for consensus call?
PTS view is that the additional requirement related to specific service are unconditional and cannot be exempted. These regards RTT in products, Annex 1, section 1 p.2 (o), (iii). Because of that the exception has to be removed. Other equipments are not required to have RTT features. Perhaps Vodafone has misconcepted this?
I see no connection with Vodafone on this issue. I think this one was an old internal issue in STF 614 about the note 3 seeming not needed because it was just saying the same as the exception in the requirement in another way. And the note 3 also had some misleading formulations. The latest proposal for the note 3 is better and matches the exception in the requirement, which seems to match the scope of the requirement in EAA.
The exception in the requirement is motivated as explained higher up in this issue and expressed in the EAA requirement in Annex I Section I point 2(o)iii which applies only “when such products have text capability in addition to voice”.
Was your comment intended to be about some other comment from Vodafone?
Edited by HELLSTROMGUN-
I propose to modify the communication client scenarios 6.0.2 and 6.0.6 to include the limitation there, matching the EAA limitation, and delete the exception from 6.2.1.1. 6.0.2 and 6.0.6 gets complex by this, but it is a way to get it closer to the intention of EAA.
6.0.2 Communication client
Where ICT is, or includes, a communication client that supports continuous bidirectional voice communication with or within a communication system that supports continuous bidirectional voice communication,
the communication client shall meet all applicable 6.1 and 6.3 to 6.6 requirements, when communicating with the communication system, and all applicable 6.2 requirements where the ICT has text handling capabilities.6.0.6 Communication client in emergency communications
Where ICT is required to provide, or otherwise provides, emergency communications, and is, or includes, a communication client that supports continuous bidirectional voice communication with or within a communication system that supports continuous bidirectional voice emergency communication,
the communication client shall, when performing the emergency communication, meet all applicable 6.1 and 6.3 to 6.6 requirements, and all applicable 6.2 requirements for cases where the ICT has text handling capabilities.6.2.1.1 RTT functionality
Where ICT provides functionality that allows continuous bidirectional voice communication~~, and would not require design changes to add input or output hardware to the ICT~~,
the ICT shall provide functionality that allows continuous bidirectional RTT communication.Delete note 3 of 6.2.1.1 and renumber the following notes.
Note 2 clarifies without change the case that the requirement is valid for ICT which can connect to external text devices
This is a very creative solution to the perceived problem with the original much simpler exception. It does however need a definition of what the EAA phrase "has text handling capabilities" means. Here is a suggested definition:
text handling capabilities: a means to accept text input from and present text to a user
Note: This would typically be the presence of a keyboard and display.
Do we have a definition for "keyboard"?
I think in this case it needs to be an alphanumeric keyboard that includes [space] and common punctuation for the local language. We discussed this previously in the context of those far more limited keyboards such as those used to enter car numbers into parking meters. Perhaps we should use "alphanumeric keyboard" here and elsewhere, and define that as also including the space and necessary punctuation keys. I'm sure individual countries have rules for what punctuation is necessary in their language(s).
-
Whatever we decide for the note, if any, I think the mentioning of text handling capability in the requirement is sufficient to exclude the parking meter. The one you describe cannot be said to have text handling capabilities. It is just character handling for entry in to a form. Text implies using words to create meaning.
added Proposed for approval label
-
Looks good except would add "or ability to connect"
text handling capabilities: a means to accept text input from, and present text to, a user
Note: This would typically be the presence of, or ability to connect, a keyboard and display.
Edited by Vanderheiden -
Combining the last two excellent suggestions leads to:
text handling capabilities: a means to accept text input from and present text to a user
Note: This would typically be the presence of, or ability to connect, an alphanumeric keyboard and display.
Edited by Michael Pluke -
cleaning up the commas and adding "device"
text handling capabilities: a means to accept text input from, and present text to, a user
Note: This would typically be the presence of, or ability to connect, an alphanumeric keyboard and display or device which can act as an alphanumeric keyboard and display
.
removed Proposed for approval label
added Included in EN label
-
Just adding a phrase to the end of the note to say it could be a device that can act as a display and keyboard -- such as AT or even a smartphone.
text handling capabilities: a means to accept text input from and present text to a user
Note: This would typically be the presence of, or ability to connect, an alphanumeric keyboard and display or device that can act as an alphanumeric keyboard and display for the ICT.
-
It is good that this change is now in the editor's draft.
We happened to have had a mail discussion resulting in some further important refinements to really satisfy the EAA requirements and SIS/PTS-010 JTB comment.
One issue is that the EAA requirement is conditioned on terminals with text capabilities, while the latest clauses 6.0.2 and 6.0.6 are conditioned on ICT with text handling capabilities, and ICT may have different scope.
Another issue is that the clauses became so complex that is is not clear how far bak the final words "where the ICT has text handling capabilities" refer. It can be read as for 6.1, 6.3-6.6 and 6.2 or only for 6.2. That must be made clear.
So, let us resolve this rapidly.
-
Here is a proposal catering for both issues mentioned above:
6.0.2 Communication client
Where ICT is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports continuous bidirectional voice communication,
the communication client shall when communicating with the communications system meet all applicable clause 6.1 and 6.3 to 6.6 requirements. Additionally, when the communication client is implemented in a terminal that has text handling capabilities, the client shall also meet all applicable clause 6.2 requirements.
6.0.6 Communication client in emergency communications
Where ICT is required to provide, or otherwise provides, emergency communications, and is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports continuous bidirectional voice emergency communication,
the communication client shall, when performing the emergency communication, meet all applicable clause 6.1 and 6.3 to 6.6 requirements. Additionally, when the communication client is implemented in a terminal that has text handling capabilities, the client shall also meet all applicable clause 6.2 requirements.
6.2.1.1 RTT functionality
Where ICT provides functionality that allows real-time bidirectional voice communication,
the ICT shall provide functionality that allows real-time bidirectional RTT communication.Delete note 3 of 6.2.1.1 and renumber the following notes.
And add the definition:
text handling capabilities: a means to accept text input from and present text to a user
Note: This would typically be the presence of, or ability to connect, an alphanumeric keyboard and display or device that can act as an alphanumeric keyboard and display for the ICT.
-
Reopened, because the version above with in 6.0.2 and 6.0.6 with "Additionally.... " was not included in the latest version of 2025-04-21
Also, the same construct with the requirements of 6.2 only applied when the terminal has text handling capabilities shall be applied on clauses 6.0.5, 6.0.8, 6.0.9.Edited by HELLSTROMGUN -
Also, the tests C.6.0.x needs modification by addition of a precondition that the terminal used for test has text handling capabilities for all except C.6.0.2 and C.6.0.6 where an extra procedure step is included testing just 6.2 if the client under test is implemented in a terminal with text handling capability.
-
@hellstromgu It is there — it is just combined with the first sentence because you shouldn’t have two SHALLS in the same provision. So the two sentences were combined into one SHALL statement
BUT I see that I lost the "terminal" restriction in the rewrite.
That yields the following -- created with Gunnar and Gregg working together.
6.0.2 Communication client
Where ICT is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports real-time bidirectional voice communication,
the communication client shall meet all applicable 6.1 and 6.3 to 6.6 requirements when communicating with or within the system, and, where the client is part of a terminal with text handling capabilities, all applicable 6.2 requirements.We also need a similar fix in 6.0.6. Here is what Gunnar and Gregg came up with.
6.0.6 Client in emergency communications
Where ICT is required to provide, or otherwise provides, emergency communications, and is, or includes, a communication client that supports real-time bidirectional voice communication with or within a communication system that supports real-time bidirectional voice emergency communication,
the communication client shall meet applicable 6.1 and 6.3 to 6.6 requirements, when performing the emergency communication, and, where the client is part of a terminal with text handling capabilities, all applicable 6.2 requirements.There is also what appeared to be a problem in 6.0.5, 6.0.8, and 6.0.9 but it was only because they had the wrong title. Correcting the title (as per issue #499) Solves the problem.
==================================================================
For reference - the definition of Terminal is
terminal: combination of hardware and/or software with which the end user directly interacts and that provides the user interface
Edited by Vanderheiden mentioned in issue #552 (closed)
marked this issue as related to #552 (closed)
-
Note to editor: remember to include edits to 6.2.1.1 and definitions indicated higher up in this issue. A corresponding change to C.6.1.1 is announced in #552 (closed).