Considerations for NENA Working Groups in Designing Web Services for Maximum Consistency: Difference between revisions

Standards commonly include functionality performed by cooperating entities using a defined interface. For example, NENA i3 specifies a logging function where various elements generate log events that are created and stored by a logging server, and entities are able to retrieve log events from the logging service.   In general, such functionality is specified using a network protocol (which allows the entities to be located on the same machine, on different machines, even on different machines in different networks, and to be provided by different vendors). Designers of such protocols may choose to create a new protocol for their purpose (which might be an entirely new protocol or a modification of an existing protocol) or to re-use an existing protocol.  When a protocol is reused, the standard specifies how the information for the functionality is conveyed using the existing protocol.  Various models are possible, although often such services use a concept of a request and a response, and often the side making a request is referred to as the client, and the side receiving the request and sending a response is referred to as the server.  Protocols may be directional (one side initiates requests and the other side responds) or not (either side may send data to the other at any time), and may be synchronous or asynchronous.  In synchronous protocols, messages are only sent at defined instances, for example, in synchronous client/server protocols, servers only send messages to clients in response to a request; in some protocols, each response can only result in one response.  Asynchronous protocols allow messages to be sent at any time or for multiple responses to be sent to a single request.  For example, an HTTP<ref>[https://tools.ietf.org/html/RFC7230 RFC7230 Hypertext Transfer Protocol (HTTP), RFC [rfc:7230 7230]</ref> server sends one response to each request; a SIP<ref>[https://tools.ietf.org/html/rfc3261 RFC3261 Session Initiation Protocol (SIP), RFC [rfc:3261 3261]</ref> server may send intermediate responses before sending a final response to an initial request, and once a SIP session has been established, either side may send messages to the other at any time; XMPP<ref>[https://tools.ietf.org/html/rfc6120 RFC6120 Extensible Messaging and Presence Protocol (XMPP), RFC [rfc:6120 6120]</ref> was explicitly designed to allow endpoints to send messages to other endpoints at any time.