]> valentin-43-44.org

valentin.internetdrafts.v-vs@v434project.com

Internet Engineering Task Force This document describes a method to store information via email and to ensure the verification of the data and identification of the version. As a long-established way of communicating and sharing information and knowledge, email is at the heart of the V verification system (V-VS).

Introduction The permanent storage of information and data is absolutely essential for a large proportion of Internet users. The name "V verification system" refers to a procedure for sending information via email and providing it with defined version identification attributes in order to guarantee the subsequent traceability of the version history. As this procedure uses the existing email infrastructure, elements such as DKIM, SPF or the encryption of email content can be used to guarantee the integrity of the data. The V verification system only uses the email infrastructure. This means that the use of the V verification system is not associated with far-reaching changes to the existing infrastructure, and compatibility with legacy infrastructures is guaranteed. Furthermore, these minimal requirements mean that the V verification system is highly flexible and can also be used in environments with limited infrastructure.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Specification The user or administrator who wishes to store data in the sense of the V verification system, MUST use their personal individual email account (example: valentin@system.valentin). The user or administrator MUST send the data to a personal, individual email address that is also uniquely assigned to them (example: valentin@admins.valentin). This address MAY be the same as the sender's address, but MAY also be an address that is different from the sender's address. The data SHOULD be in the message body of the email. The message body itself MAY be formatted as Plain text (flat US-ASCII text)([RFC822]) or MIME (). The subject of the email SHOULD include the project name or the name of the data to be stored, the current date in the format YYYYMMDD and the current time in the format HHMM as well as a random value. The subject of an email could therefore look like this: "PROJECTXYYZ202406181520 VB" In order to improve the durability of the data or to enable collaboration with other people, these mails MAY also be addressed to a mailing list or to various other people in addition to the personal email address. The minimum requirements of the V verification system are described in this document. All further details on how the user wishes to use the V verification system are the sole responsibility of the user.

Security Considerations According to the author, no security considerations apply to this document.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] Informative References The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772. This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.