TWiki . NCITSV2 . RequirementsForRemoteConsoleStandard	TWiki . { Main | TWiki | NCITSV2 | Know | Test }
	NCITSV2 . { Home | Users | Offices | Changes | Index | Search | Go }

See also OtherConsiderationsForRemoteConsoleStandard and TechnicalConsiderationsForRemoteConsoleStandard.

Text-Based Interaction Protocol

(1) The standard must require that the target device provide to the remote console all information that the target device usually presents (in any form including visual, auditory, tactile, olfactory, etc.). This information must be provided via the protocol in human comprehensible electronic text. If the content is not inherently translatable into text (e.g. geographic information, instrumental music, Data Mining, force feedback, etc.), or if the content was generated by a third party and the target device is not able to find or create a text equivalent (e.g. a document/web page containing a graphic with no text description), then the target device must provide text indicating the presence and nature of the untranslatable information.

(2) The standard must require that the target device present all functions that the target device is capable of performing to the remote console via the protocol in a form that can be easily rendered into human comprehensible text by the device. "Human comprehensible text" is a string that consists of natural language characters (e.g. printable Unicode characters) and represents a natural language construct to the user.

(2a) The standard must require the target device's commands be transmittable in natural language characters (e.g. printable Unicode characters). [ v2a: suggest modification NoteReqV2a20020319 ]

Structure of Information and Control Items

(8) The target device must represent every set of control items and all device information items in such a way that a linear presentation of items (i.e. one item at a time) will be comprehensible to the user. In addition, the text describing each item must also be comprehensible when presented linearly (one character or word following another sequentially).

(8b) Control items chosen by the user, as sent from the remote console to the target, must be represented in a manner that identifies a unique command without requiring any contextual information such as knowledge by the target of the command set being currently viewed by the user. (Though the target may interpret control items in the light of its current state.)

(8c) The protocol must preserve ordering of information and control items as given by the target.

(8a) If information and control items are (e.g. hierarchically, tabular) grouped the standard shall support the transmission of the grouping to the remote console.

(9) In addition to the linear presentation the standard shall allow transmission of additional information to facilitate the remote console's presenting the information and control items in non-linear, or non-text forms (e.g. graphical button on a LCD touch screen).

(16) The standard supports having a remote console which lets the user group controls from different target devices into a single user-constructed menu on the remote console.

Timeout

(3) Application controlled timed events (e.g., time outs, response requirements, etc.) must be (1 or more of the following options):

• (a) able to be turned off (no time dependent responses), or

• (b) adjustable by the user to five times the default response time (or presentation time), or

• (c) provide a warning of a time out and allow at least five seconds for the user to respond.

[ GV: 10 seconds? NoteReqRCGregg20011123b ]

Note: This requirement is separate from real (non-application controllable) event timing. For example, driving a car requires that an individual be able to respond within a certain period of time in order to keep the car on the road.

Help Text

(17) The standard shall support optional help text for the information and control items.

Internationalization

(15) The standard shall support multiple natural languages. The protocol shall provide support for:

• conveying information in different languages,
• identifying the language to the remote console, and
• letting the user choose a language.

Various Target Devices

(5) The standard must not require that the remote console have any prior knowledge of the target device including any knowledge of its commands, command structure, language, type, etc., beyond those specified by the protocol.

Device Identification

(18) The standard shall require the target device and remote console to identify themselves (including product manufacturer and version).

Discovery

(7) The standard must be compatible with an underlying network protocol which is able to poll and scan the environment and allow the user to select a desired target for interaction from a presentation of available targets. This includes support for communication with multiple targets.

Connection

(4) The standard must not require connection to the Internet.

(6) The standard shall be applicable in a limited bandwidth environment.

(11) The standard shall establish and maintain the certainty of connection with a single (or multiple) remote console(s) so that the target device can determine when the remote console(s) depart(s).

Event Notification

(10) The standard needs to provide a mechanism for the target service to communicate asynchronous changes (about the target device's status) from the target device to the remote console.

Security

(13) The system shall implement security features to protect the security and privacy of transactions conducted via this alternative interface."

Reset

(12) The standard shall include a 'reset service' command. The target service must notify the remote console when a reset is complete. The impact of the reset command is specified as follows:

• If the service has a default 'power on' state, reset will return the service to this state. It is effectively a power off/power on for devices, or closing and reopening a software program.
• Any transaction already completed and confirmed or saved will not be undone.
• Incomplete transactions will be abandoned and not saved.

(12a) The standard shall include a 'remote console disconnect' event that is sent from the remote console to the target service. The target service must respond to this event as follows:

• For single user services (e.g. ATM) a remote console disconnect would be equivalent to a reset command requested by the remote console.
• For multi-user services (e.g. television) it is up to the target how to react to a remote console disconnect.

(12b) In case of a loss of physical connection, it is up to the target service how to react, e.g. performing a reset operation immediately, or only after a certain timeout. We recommend, where reasonable, that the target service prompt the user whether or not they want to resume their dialog, if the connection has been reestablished within a certain amount of time. In either case, the state of the target service must be made clear to the user after re-connecting. If the target service has been reset due to a loss of physical connection, requirement (12) applies regarding the notification and impact issues.

-- Main editor: GottfriedZimmermann - 08 Feb 2001

Topic RequirementsForRemoteConsoleStandard . { Edit | Ref-By | Attach | Diffs | r1.18 | > | r1.17 | > | r1.16 | > | r1.15 | >... }

Revision r1.18 - 20 Mar 2002 - 16:02 by Main.sharitrewin

Copyright © 2000 by the contributing authors. All material on this collaboration tool is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback.