NHCP - Nathan's Human Connection Protocol

March 7, 2025

Status of this Memo

This document specifies the Nathan's Human Connection Protocol (NHCP), version 1.0 as practice for the IEEE April Fools' Day RFC.

Abstract

This document specifies the Nathan's Human Connection Protocol (NHCP). NHCP standardizes the request, response, message, resend, and keep-alive mechanisms involved in human communication scenarios. This protocol aims to enhance the predictability and reliability of human interactions by formalizing communication exchanges.

Introduction

Human connections are vital to social interaction. However, these connections often fall prey to misunderstandings, improper acknowledgements, and unpredictability, leading to inefficiency and/or communication breakdown.

NHCP aims to provide a structured approach to managing these interactions and reduce the aforementioned issues by providing a standardized set of rules to communicate for initating, responding to, and maintaining these interactions.

NHCP is designed specifically for digital communication environments, addressing the challenges of miscommunication and unpredictability in online interactions. While the principles of NHCP are inspired by human social interactions, its practical application is limited to digital mediums.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

Message: A structured communication unit within the NHCP protocol, containing a Type, Identifier, Timestamp, and Body. Messages MUST be one of type Request, Response, Message, Resend, KeepAlive, and Termination.
Requester: The entity that initiates the connection.
Responder: The entity that responds to the connection request.
Connection: A bidirectional channel of communication established between a Requester and a Responder.
KeepAlive: A mechanism for maintaining the established connection.
Timestamp: The time at which a Message is created, represented in UTC using the ISO 8601 format: YYYY-MM-DDTHH:MM:SS[.sss]Z.
Content-Type: A field within the Message that specifies the media type of the Payload, following the standard HTTP Content-Type definitions (RFC 7231).
Cool-off Period: A predefined duration following a Reject Response, during which the Requester SHOULD NOT attempt to re-initiate a Connection with the Responder. The length of this period should be defined by the implementation.
Identifier: A unique string assigned to each Message, used for message tracking, referencing, and Resend operations. It MUST be uniquely generated by the sender and MUST follow a sequential order. Client-generated messages and server-generated messages SHOULD use separate identifier spaces to avoid conflicts.

Protocol Overview

Request: Initation of connection.
Response: Acknowledgement and acceptance, rejection, delaying, or forwarding of the connection request.
Message: A user-defined communication that is sent during an active connection, containing content as specified by the Content-Type.
Resend: A request to retransmit messages sent after a specific Message Identifier, used to recover missed or unacknowledged messages.
KeepAlive: Maintenance of connection over time.
Termination: Termination of established communication channel.

Message Format

All NHCP messages MUST consist of the following fields:

Type: Specifies the message type (Request, Response, KeepAlive, Termination).
Identifier: Specifies the message ID. It MUST be uniquely generated by the sender and MUST follow a sequential order. Client-generated messages and server-generated messages SHOULD use separate identifier spaces to avoid conflicts.
Timestamp: The time the message was created. Timestamp MUST be represented in UTC using the ISO 8601 format: YYYY-MM-DDTHH:MM:SS[.sss]Z.
Body: The content of the message.

Request Operation

Request Format

A Request message is used to initiate a connection. The Body field of the Message SHOULD contain a brief introduction and MAY additionally contain a topic of discussion.

Type: Request
Identifier: <MessageIdentifier>
Timestamp: <UTC Time>
Body: <Introduction and Topic>

Request Handling

Upon receiving a Request, the Responder MUST process it and generate a Response message. The Requester MUST wait for this Response before any further action.

Response Operation

Response Types

There are four possible types of Response messages:

Accept: The Responder agrees to establish the connection.
Reject: The Responder declines the connection request.
Delay: The Responder acknowledges the request but cannot respond immediately.
Relay: The Responder forwards the connection request to a third party, who MAY be better suited to respond.

Response Format

Type: Response (Accept/Reject/Delay/Relay)
Identifier: <MessageIdentifier>
Timestamp: <UTC Time>
Body: <Acceptance Message, Rejection Message, Delay Explanation, or Relay Details>

Accept: Upon receiving an Accept Response, the Requester and Responder SHOULD begin communication over the established connection.
Reject: If a Reject Response is received, the Requester SHOULD NOT attempt to re-initiate the connection for a predefined cool-off period.
Delay: A Delay Response indicates the Responder WILL follow up when they are ready. A Delay Response MAY include an estimated wait time.
Relay: If a Relay Response is received, the Requester SHOULD wait for a response from the third party. The Relay Response MUST include contact details or an introduction to the third party.

Message Operation

Message Format

Type: Message
Identifier: <MessageIdentifier>
Timestamp: <UTC Time>
Content-Type: <Content Type>
Reference-Identifiers: [<MessageIdentifier1>, <MessageIdentifier2>, ...]  
Body: <Message>

The Message operation is a user-defined message and MUST be interpreted according to the content type specified in the Content-Type field. The content of the Body is user-defined and should be processed according to the specified Content-Type.

Content-Type Field

The Content-Type field specifies the media type of the message content. This MUST be set to one of the standard HTTP content types, as defined by RFC 7231 and related HTTP standards.

Reference-Identifiers Field

The Reference-Identifiers field is OPTIONAL. When present, it MUST contain an array of MessageIdentifiers, each representing one or more related messages. These identifiers provide context or indicate the chain of related messages. If the field is not included, no references are provided for the current message.

Resend Operation

Resend Format

Type: Message
Identifier: <MessageIdentifier>
Timestamp: <UTC Time>
LastRecievedMessage: <MessageIdentifier>

The Resend Operation is used to request the retransmission of all messages that were sent after a specific MessageIdentifier. The LastReceivedMessage field indicates the identifier of the last message successfully received by the sender, and the sender requests the retransmission of all messages sent after this message.

The responder MAY choose to honor the request and SHOULD attempt to resend as many messages as possible that were sent after the specified LastReceivedMessage. However, the responder is NOT required to respond with any messages. The responder is under no obligation to have any messages available for retransmission and SHOULD NOT be expected to provide a response in all cases.

KeepAlive Operation

KeepAlive Format

Type: KeepAlive
Identifier: <MessageIdentifier>
Timestamp: <UTCTime>
Body: <Status Update or Simple Greeting>

KeepAlive messages are used to maintain an active connection. Either side (Initiator or Responder) MAY send a KeepAlive message periodically to ensure the connection remains active. These messages MUST be acknowledged by the recipient to confirm that the connection is still valid. To prevent excessive network traffic, both sides SHOULD NOT send KeepAlive messages more frequently than once within a predefined timeout interval. A side MUST NOT send more than one KeepAlive message during the timeout period.

KeepAlive Handling

If a KeepAlive message is not acknowledged within a predefined timeout period, the connection SHOULD be considered lost, and both parties MAY reinitiate the connection if desired.

Termination Operation

Termination Format

A connection CAN be terminated explicitly by either party at any time. Termination MAY be unilateral but MUST be communicated with a final message:

Type: Termination
Identifier: <MessageIdentifier>
Timestamp: <UTC Time>
Body: <Closure Explanation>

Upon receiving this message, the other party SHOULD acknowledge the termination, and the connection SHOULD be officially closed.

A Closure Explanation is OPTIONAL and SHOULD NOT be expected to be present in all cases.

Security Considerations

NHCP does not inherently define mechanisms for authentication, confidentiality, or integrity. Implementations of NHCP MUST ensure that communication channels are secured using appropriate security protocols such as TLS (Transport Layer Security). It is also important that implementations consider the risk of Denial-of-Service (DoS) attacks, as unsolicited requests or excessive message flooding could disrupt communication.

The protocol does not mandate encryption of message content; however, to protect privacy and ensure confidentiality, implementations SHOULD apply encryption as necessary based on the sensitivity of the message content.

IANA Considerations

This document does not require any new IANA registrations.

Conclusion

Nathan's Human Connections Protocol (NHCP) provides a structured framework for human communication that aims to improve reliability and predictability in interactions. By defining standardized message formats and operations, such as Request, Response, Message, Resend, KeepAlive, and Termination, NHCP addresses common challenges in communication, including miscommunication, unacknowledged messages, and connectivity issues.

References

Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
International Organization for Standardization (ISO). "ISO 8601:2004 – Data elements and interchange formats – Information interchange – Representation of dates and times."
Fielding, R., et al. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content," RFC 7231, June 2014.

Acknowledgements

The authors would like to thank Eliseo Martelli for inspiring the development of this protocol with their Human Connection Protocol.