RFC for the protocol between a voice-activated personal assistant and universal computing 

The purpose of this document is to establish a vendor-independent open framework for integration between a front-end personal assistant and a back-end universal computing. While writing a new protocol has become less active as compared to the proliferation of web services and accepted medium of communication over the HTTP via Representational State Transfer (REST) APIs, this document assumes and hopes that developers will fall back to these principles just as they did with other open frameworks such as OpenID. Although RFCs come with proof-of-concept, this document merely tries to enumerate the rules which have themselves been picked from other standards or gained acceptance in the industry. 

1) Voice is a form of identification as much as tokens are, given the scope in which it is valid. It may be used in conjunction with other credentials such as passwords or PINs. It may also be collaborative with sign in to associated devices such as the desktop or phone and it can be a point of contact standalone authenticator as opposed to login from social engineering application. In all these cases, the personal assistant must know who the owner is. Consequently, OpenID and extensions that address fragmented identity should be implemented in the personal assistant software. 

2) Personal Assistant may have a jargon that is either built-in or expanded with experience. These may take the form of a rules engine that has nouns and verbs associated and logic expressed as conditions on the verbs. The jargon itself is open to the owner and customizable via programming on desktop. It can be backed up in the cloud or exported and imported. Sync to this jargon happens in an object-oriented way as derived from the publisher or implemented from industry standards or supported from external clients such as desktops or mobiles. Verbs may involve such things as search, sort and rank that can use published algorithms or packages which can execute remotely. Much of the processing is delegated so the personal assistant only keeps track of the customizations for the owner. 

3) The interfaces implemented by the personal assistant involve read and writes to universal stores, delegation of commands to other devices and computing, establishing connections with devices and libraries over different networks and adding learned logic or associations to the jargon. The personal assistant does not need to have an enterprise grade software, rather it needs to be an agent for an enterprise based server software that can operate in standalone as well as connected to the server. The networks are implemented over bluetooth for device to device connectivity and over wifi for internet connectivity 

4) The personal assistant also maintains a message bus for relays from the server, other processors and other agents with a simple and universal envelope that can be implemented even between co-ordinators. The REST services may come in helpful here but the assistant ensures a time-to-live on each envelope so that inbound and outbound queues may be refreshed as per the session with the owner. Since the entire device is for the owner, there is no separation of queues for different users and no priority difference between messages. 

5) The personal assistant exposes its activities by sharing its log that can be exported and archived externally. It may also support points of injection of logic for appropriate use by the publisher and enforcement agents.