Project Proposal to Develop a New Standard
Alternate Interface Access Protocol —
Standard Resource Descriptions


1. Source of the Proposed Project

1.1 Title
Alternative Interface Access Protocol—Standard Resource Descriptions

1.2 Date Submitted
January 20, 2004 

1.3 Proposer(s)
The INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2).

Four organizations (IBM, NIST, Panasonic, & Unisys) are members of both INCITS/V2 and the INCITS Executive Board.

2. Process Description for the Proposed Project
2.1 Project Type (Development or Revision)
Development ("D")

2.2 Type of Document
Standard

2.3 Definitions of Concepts and Special Terms
See attached: Terms of Reference

2.4 Expected Relationship with Approved Reference Models, Frameworks, Architectures, etc.
There are a number of existing protocol and modeling activities being undertaken by the Internet Engineering Task Force (IETF), the World Wide Web Consortium (W3C), and other consortia and specification development activities that we are coordinating with.  We are working with INCITS/L8 to ensure that necessary data definitions, metadata, as well as shared data registry and registration authority definitions are specified correctly and similarly with INCITS/T4 to ensure that security and privacy issues are appropriately addressed.

          2.5 Recommended INCITS Development Technical Committee (Existing)
        The INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2).
2.6 Anticipated Frequency and Duration of Meetings
INCITS/V2 meets 4 times a year at various locations throughout the U.S. in 2 to 4 day face to face plenary meetings.  Working meetings are held as needed by different ad hoc teams. These meetings are held by telephone conference, video conference, and other means when feasible to save time and resources and to allow maximum participation by the broadest spectrum of interested parties.  Over 50 of these working meetings have taken place over the last year.

2.7 Target Date for Initial Public Review (Milestone 4)
April 15, 2004
 
2.8 Estimated Useful Life of Standard or Technical Report
At least 5 years.
3. Business Case for Developing the Proposed Standard or Technical Report
3.1 Description
This proposed American National Standard will be one in a series defining the Alternate Interface Access Protocol (AIAP) and the  Universal Remote Console (URC). The goal of this set of standards is to provide a framework of components that combine to enable remote User Interfaces and remote control of network accessible electronic devices and services through a Universal Remote Console (URC).

The AIAP is a set of standards for the discovery, selection, configuration, and operation of user interfaces and options.  The purpose of the AIAP-URC standards is to facilitate the development and deployment of a wide variety of devices (from different manufacturers) that can act as Universal Remote Consoles (URCs) for an equally varied range of devices and services (called "Targets").  In other words, the  standards will allow users to control any number of Electronic and Information Technology devices in their environment.

The potential Targets include both devices and services.  They may range from things as simple as light switches and thermostats, to more complex items such as audio visual equipment, home appliances, electronics in cars or other constrained or specialized environments, web-based services, and any other devices or services that can be controlled electronically (or via Communications or Information Technology -- CIT). 

Targets may be in the same location as the individual who desires to control the Target through the URC, or the Target can be at any distance from the URC/user, as long as there is some type of network connection between the URC and the Target.  This is possible since a URC provides the user with all of the necessary controls as well as the prompts and other information displayed by the Target.

URC functionality could be provided by common devices such as personal computing and Information Technology devices (e.g. laptops, PDAs), telecommunications/WAP devices (e.g. cell phones), etc. They could also be functions implemented in assistive technology devices, or they could be devices that were specially built to function as Universal Remote Consoles.  They may also be devices that were built to function primarily as Remote Consoles for a particular family of products (e.g. a Remote Console designed to control components of an integrated home audio-visual system), but would also serve to control any other device that is AIAP-URC compatible.  They are similar in behavior to universal remote controls today, except

a) they have much greater function and scope,

b) they synchronize with the Target in both directions (i.e. they can display the current status of the Target),

c) they don't need to be programmed by the user, (since they will automatically discover devices that are controllable in a user's vicinity, discover the abstracted user interface of the Targets and present it in the way preferred by the user), and

d) depending on the networking technology used, they may be used out of sight of the product they are controlling.

The output interfaces provided by URCs could be all visual, all tactile, or all verbal in nature (or any combination thereof), because the AIAP-URC specifies the content of a Target user interface independently from the form in which it is presented.  Similarly and for the same reason, the control interfaces may be by voice, keyboard, mouse or any other available input technology.  Thus, URCs could be designed that an individual could talk to and, through the URC, the user could have speech access to any AIAP-URC compatible Target listed above without any of these Targets having any voice recognition or voice control functionality themselves.  A person might, therefore, be able to say to their URC, "Record channel 12 and show me 'Law and Order'".  Or they could be laying in bed and say, "Set the alarm to 6:30 AM, turn the coffee on at 6:00 AM, and turn on the home security system".  Or, if one's spouse is already asleep, a person could pick up their PDA or any other AIAP-URC compatible URC device and accomplish these same tasks silently either by calling up control panels or by issuing the instructions in writing. (The AIAP-URC standards do not provide the natural language control, but would provide all of the information and control necessary for control by a natural language processing URC.)

The purpose of the specification on Standard Resource Descriptions of the Alternate Interface Access Protocol is to define the syntax for describing Resources relevant to the user interface of a device or service ("Target").  These Resources include text elements of a user interface such as labels, help text, keyboard shortcuts (access keys) and associated words (keywords).  They may also include non-text elements such as icons, sounds or videos.  A Resource makes reference to a specific element in an AIAP Socket (described in an AIAP User Interface Socket Description), to a specific element in a Target Properties Sheet, or to a specific element in an AIAP Presentation Template.

This document provides the specification for development of an AIAP Standard Resource Description.  The following additional documents have been defined separately and specify other specific languages and components of the AIAP-URC standard:

3.2. Existing Practice and the Need for a Standard
No standard or specification exists for defining a user interface (UI) for an arbitrary electronic or information technology device or CIT service that is independent of mode of UI rendition or instanciation.  Such mode independent UI descriptions together with robust specifications for UI rendition and instanciation , defining a "Universal Access Bus," are essential for simplifying and normalizing our increasingly complex, increasingly computer dominated environment. 

The existence of such a universal access bus for consumer products, environmental controls, appliances, web services, etc. will also benefit people with disabilities and the aging population by helping organizations meet state and Federal requirements for universal access to services, data, and information.

3.3. Implementation Impacts of the Proposed Standard
3.3.1 Development Costs
This Standard will be developed through the voluntary and cooperative efforts of INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2) members. No significant development costs are anticipated.

3.3.2 Impact on Existing or Potential Markets
There is a burgeoning market already for personalization of content and appearance on the World Wide Web, with regard to small handheld devices and for commercial sales purposes.  Companies such as IBM, ATG and Vignette, among many others, have products and services for this explicit purpose.  This market is expected to grow considerably in the next 3 years.  There is also a movement  in the Web to provide sites of interest to people with disabilities (e.g., HalfthePlanet, WeMedia, CanDo) and the aging population (e.g., SeniorNet), and attempts to bring the W3C WAI recommendations into these.  Alternative interfaces to meet these needs, whether pre-constructed, adapted or constructed on the fly, are a form of personalization.

Another rapidly emerging segment of technology is that of pervasive computing, whereby intelligent devices of all sorts are distributed into the living environments of home, shopping, and other activities involving mobile systems. Of particular note are the numerous offerings in:

This follows the burgeoning of wireless technology from companies such as Qualcomm, Nokia, Ericsson, and Motorola, to mention but a few, as well as activities such as the Wireless Application Protocol Forum (WAPForum) and the Salutation Consortium in promoting applications for wireless devices.  Handheld devices such as the 3Com Palm and the Pocket PC are targeted at the mobile computing environment.  Another important factor in the wireless environment is the Bluetooth RF infrastructure for which a very substantial number of manufacturers are building compatible devices.

Whereas these services look towards increasing access for user's critical information, they rely on end-users to configure, change, or maintain configurations for their access.    In addition, the burden of incorporating multiples of these offerings into a daily regimen is taxing on the user, and certainly highly error-prone.  The key shortfall, however, rests in the personalization of the user's interaction with each of these separate systems, and the changes and dynamics that individual users' will need to effectively coordinate and use these services effectively.  This can be made especially difficult for a user with a disability or who is aging.

To make these systems truly usable, service providers must bridge the user's networks (office, mobile, home); the user's devices (phone, web-pad, computer); and the user's information spaces (email, documents, news/information).

Key to interaction across devices and information spaces is the ability to provide the solution in a ubiquitous form factor.  Two related initiatives are needed:

The AIAP is seen as the integrating factor for these initiatives.  Moreover, the AIAP will be a major factor in providing preference and capability transfer in non-networked, non-mobile uses as well.  The Composite Capabilities and Preferences Profiles (CC/PP) effort in W3C is aimed at standard representation of  the capabilities and preferences for users and devices.  The WAPForum has been using the CC/PP to describe the features and capabilities of some wireless devices such as smartphones.

There is at least one company, edapta, Inc., that is already building a system based around only the requirements document that the NCITS ITA SG has produced so far. They expect to have public demonstration of their beta product in the summer of 2000.  Some of the market information here comes from their analyses.  The liaison between the NCITS ITA SG and the CC/PP group is an employee of edapta, and is in the W3C WAI.

Moreover, there is an abundant market for third-party developers to build products that will carry out interface transformations for content, appearance and user controls and to build applications that lend themselves to interface selection or transformation.  Many of these already exist.  Netscape has released its Versions 6 browser which permits widespread modification of both its operating interface and the content appearing on it, through a language called XUL (extensible User interface Language).  There is also another language called User Interface Markup Language that uses Sun Microsystems’ Java Swing for modifying rendering of interface elements.  Both of these languages are compatible with and expressible by the W3C language XML.  Sun is also pushing its Jini connection technology as a means of mediating access to alternative interfaces (the AIAP would run over Jini).  Other venues for the AIAP include the Salutation Consortium’s Salutation architecture, HomeAPI/Universal Plug and Play, and HomeRF.

The AIAP is also being seen as part of the solution for meeting the Access Board procurement standards for electronic and information technology, pursuant to the provisions of Section 508 of the 1998 amendments to the1973 Rehabilitation Act.  Thus, some equipment procured by the Government could have the AIAP specified as meeting some of the requirements of the 508 procurement standards.

Numbers from analysts range up to 1 billion wireless devices shipped by 2004; 10 million digital homes by 2004; and 41 million telecommuting/ SOHO workers by 2003.  The total addressable market of an enabling technology such as interaction personalization can be estimated at 100M people in North America & Europe within 3 years.  Related investments in wireless data, personalization, and unified services are in the multi-billion dollar area.  There are 70 million adults aged 50+; this is expected to grow to 115 million in the next 25 years.  Of the present 70 million, 13 million have Internet access (SeniorNet and Charles Schwab), or 16.5% of total online population, and they spend 30 hours per month online, 47% higher than the national average.  A significant portion of these users has difficulty in using a mouse and navigating the Web, and operating other applications.  About 8% of the total U. S. population has a disability that limits their ability to use a computer or to have effective access to the Internet.  People with disabilities are under-represented in the work force and make up a considerable portion of the population that is at low-income levels.

3.3.3 Costs and Methods for Conformity Assessment
A conforming AIAP Target must implement:

A Target's manufacturer can also provide documents of the Portal Core separately as a supplemental Resource, if the Target is a legacy product that already provides the necessary communication and control functionality through a networking platform (such as UPnP or Jini/Java). 

A conforming URC must implement:

Other components can claim conformance as AIAP-URC Subcomponents by conforming to the respective subcomponent Standard.

Conformance will be determined by industry interoperability testing methods.  The costs for such testing will be born by the component (URC or Target) developer or manufacturer.
 
3.3.4 Return on Investment
The return on investment for this development is expected to be high, due to the complexity and cost to individuals and their employing organizations of  using the current methods of interface configuration in the areas covered by the proposed Standard.
3.4 Legal Considerations
3.4.1 Patent Assertions
Calls will be made to identify assertions of patent rights in accordance with the relevant NCITS, ANSI and ISO/IEC policies and procedures. At this time, INCITS/V2 members are unaware of any patent assertions that may be made.

3.4.2 Dissemination of the Standard or Technical Report
Drafts of this document will be disseminated electronically. Dissemination of the final Standard will be restricted as the document becomes the property of NCITS, ANSI, or ISO/IEC.
4. Related Standards Activities
4.1 Existing Standards
There are no known protocols at the Human Computer Interface.

4.2 Related Standards Activity
IETF ZC WG
HFES
ISO/IEC JTC 1 SC 35 User Interfaces

Note: as the U.S. TAG to ISO/IEC JTC 1 SC 35 User Interfaces, INCITS/V2 will be working closely with the Internation community to ensure the broadest possible acceptance of the AIAP standards.  We intend to submit a parallel NP for development of a multipart AIAP ISO/IEC International Standard.

4.3 Recommendations for Close Liaison
IETF ZC WG
W3C/WAI Protocols and Formats WG
INCITS/L8
5. Units of Measurement used in the Standard
    Not Measurement Sensitive

NOTE-- The explanatory text below is included in the INCITS Project Proposal Template (RD3). It is included here for our convenience while considering this proposal.  It will be removed from the final, approved project proposal prior to transmittal to INCITS Staff for INCITS review.
Explanatory Text Follows:

1. Source of the Proposed Project

1.1 Title
Provide a descriptive subject matter title.
1.2 Date Submitted
The date should be the date of submission of the proposal to the INCITS Secretariat.
1.3 Proposer(s)
If an INCITS Technical Committee (TC) is the proposer, how many TC members are also members of INCITS?

If the proposer is not an existing INCITS TC, identify the individual who will serve as the acting chairman until a new TC has been established.

2. Process Description for the Proposed Project
2.1 Project Type (Development or Revision)
Indicate "D" if DEVELOPMENT will be done within an INCITS Technical Committee and the expected result is an ANSI standard.

Indicate "DT - A" if the project proposal describes a proposed ANSI technical report;

Indicate "DT - N" if the project proposal describes a proposed INCITS technical report.

Indicate "R" if the project proposal describes a proposed REVISION to a standard or technical report.

2.2 Type of Document
Specify the type of document to be developed (standard or technical report).
2.3 Definitions of Concepts and Special Terms
Provide definitions of key concepts and special terms (if any) needed in developing and understanding the document.
2.4 Expected Relationship with Approved Reference Models, Frameworks, Architectures, etc.
Identify relevant reference models, frameworks, architectures, etc., that are being used to conceptualize the relationships among the various information technologies and this project, and any known or anticipated areas of conformance or conflict.
2.5 Recommended INCITS Development Technical Committee
Indicate a preference for assignment of the proposed project to a particular existing Technical Committee, or propose creation of a new INCITS TC. Creation of a new TC must include the rationale. Include a description of available resources -- at least four individuals and organizations competent and interested in the subject matter --to assure that adequate resources exist to accomplish the proposed program of work. Indicate which are members of INCITS.
2.6 Anticipated Frequency and Duration of Meetings
Estimate of the anticipated frequency and duration of meetings.
2.7 Target Date for Initial Public Review (Milestone 4)
Estimate the target date for releasing the draft document for public review (described as Milestone 4 in section 5.1 of the INCITS/SD-2, Organization, Rules and Procedures.).
2.8 Estimated Useful Life of Standard or Technical Report
Estimate the useful life of the document.
3. Business Case for Developing the Proposed Standard or Technical Report
3.1 Description
Describe the technical information that will be covered by the document.
3.2 Existing Practice and the Need for a Standard
Identify why a standard is needed, rather than another kind of solution.

Describe existing practice in the area of a proposed document to aid in judging timeliness and appropriateness of the project.

Address the expected stability of the proposed document with respect to both current technology and potential technological advances.

3.3 Implementation Impacts of the Proposed Standard
This section addresses the potential impacts of the proposed standard. To the extent possible, the proposer is requested to address the following implementation considerations:

3.3.1 Development Costs

Provide an overall estimate of the technical development costs for this standard.

Include labor costs for technical editor(s), logistical costs for meetings, work between meetings, and any other significant costs.

3.3.2 Impact on Existing or Potential Markets
Provide a cost/benefit statement (qualitative or quantitative) on the impact on users and suppliers, should this standard be implemented.

Describe any potential markets (using publicly-available economic data from security analysts, market trend or venture capital reports, etc.), should this standard be implemented.

3.3.3 Costs and Methods for Conformity Assessment
What testing environment is appropriate for this technology (e.g., suppliers' declaration, accreditation of testing laboratories, certification bodies)? Will this standard contain the necessary and sufficient testing information for assessing conformity to this standard? If not, how will this information be developed, and what are the associated development costs?
3.3.4 Return on Investment
What is the estimated ROI for development of this standard and the conformity assessment costs associated with it?
3.4 Legal Considerations
3.4.1 Patent Assertions
Calls will be made to identify assertions of patent rights in accordance with the relevant INCITS, ANSI and ISO/IEC policies and procedures. Is the proposer aware of any patent assertions that may be made? If so, describe.
3.4.2 Dissemination of the Standard or Technical Report
Drafts of this document will be disseminated electronically. Dissemination of the final standard will be restricted as the document becomes the property of INCITS, ANSI, or ISO/IEC. Is the proposer aware of any IPR assertions that will hinder this distribution? If so, describe
4. Related Standards Activities
4.1 Existing Standards
Identify existing standards (including but not limited to INCITS, ANSI, and ISO/IEC/JTC1) that may affect or be affected by the proposed project.
4.2 Related Standards Activity
Identify projects under development (including but not limited to INCITS, ANSI, and ISO/IEC/JTC1) that may affect or be affected by the proposed project. For each project identified, indicate if the liaison arrangements have been made with these activities."
4.3 Recommendations for Close Liaison
Recommend which NCITS subgroups should be identified as close liaisons.

[Close liaisons require an exchange of information, but the work of one is not dependent upon the work of the other.]

5. Units of Measurement used in the Standard
Indicate units of measurement used in the Standard: