Requirements for Remote Console Standard

 

This is a draft of preliminary requirements and considerations for an (alternate) Remote Console standard.

 

(1) The standard must require that the target device provide all information that the target device usually presents visually or auditorially to the remote console via the protocol in human comprehensible electronic text (e.g. Unicode).

[If content is not inherently translatable [GZ1] into text this is out of scope (e.g. GIS, Music, Data Mining, force feedback, etc.)?]

 

(2)[GZ2]  The standard must require the target device to present all functions that the target device is capable of performing to the remote console via the protocol in human comprehensible text (e.g. Unicode) and that the command back to the target device be transmittable in human comprehensible characters[GZ3]  (e.g. Unicode). (For example, pick from list and send a code for list item or list item number back.)

 

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

(a)[GZ4]  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 (10?) seconds for the user to respond.

[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.]

 

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

 

(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.

 

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

 

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

 

(8) The target device[GZ7] âs information and control items shall be representable in a linear manner (e.g. unique numbers).

(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).

 

(10) The standard needs to be able to communicate asynchronous changes (about the target device's status) from the target device to the remote console.

[Note: Should we allow asynchronous status messages in both directions?]

 

(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).

[Note: "ping"[GZ8]  feature: is there any other status information that the target device needs to know from the remote console?]

 

(12)[GZ9]  The standard must specify what the target device does with reset command and with remote console disconnect event (this is necessary for user expectation). The target device must notify the remote console when reset complete.

 

(13) [GZ10] The standard must support security and privacy features: - at least as secure and at least as private as the default target user interface.

 

(15) The standard shall support multiple natural languages.

[Note: 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.]

 

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

[Note: This could be achieved by the atomic protocol requirements:- Unique device ID, and

- stable (unique) command ID (only for non-context sensitive commands).

 

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

[Note: This could be by query on the part of the remote console, or as part of the menu list.]

 

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

 

Other Considerations

 

(i) Cheap remote console devices.

 

(ii) Scalability of presentation modes (e.g. scalable graphics).

 

(iii) Voice input should be one practicable mode for controlling the remote console.

 

(iv) Support animated and interactive objects for representing and making choices.

 

(v) Support the use of AI / heuristics in the remote console to figure out the meaning of ãincompleteä commands.

 

* (vi) Standard should support the ability to communicate graphics and other non-text presentations. Able to define media fragments as functionally equivalent and hence alternatives one for another.

 

(vii) The protocol should be extensible (support future functionality and features).

[Note: e.g. version identification and backward compatibility.]