infra.spec.whatwg.orgInfra Standard

Infra Living Standard — Last Updated 24 January 2024 Participate: GitHub whatwg/infra ( new issue , open issues ) Chat on Matrix Commits: GitHub whatwg/infra/commits Snapshot as of this commit @infrastandard Tests: web-platform-tests infra/ ( ongoing work ) Translations (non-normative) : 日本語 Abstract The aims to define the fundamental concepts upon which standards are built. Table of Contents Goals 1 Usage 2 Conventions 2.1 Conformance 2.2 Compliance with other specifications 2.3 Terminology 2.4 Privacy concerns 3 Algorithms 3.1 Conformance 3.2 Avoid limits on algorithm inputs 3.3 Declaration 3.4 Parameters 3.5 Variables 3.6 Control flow 3.7 Conditional abort 3.8 Conditional statements 3.9 Iteration 3.10 Assertions 4 Primitive data types 4.1 Nulls 4.2 Booleans 4.3 Bytes 4.4 Byte sequences 4.5 Code points 4.6 Strings 4.7 Time 5 Data structures 5.1 Lists 5.1.1 Stacks 5.1.2 Queues 5.1.3 Sets 5.2 Maps 5.3 Structs 5.3.1 Tuples 6 JSON 7 Forgiving base64 8 Namespaces Acknowledgments Intellectual property rights Index Terms defined by this specification Terms defined by reference References Normative References Informative References Goals Deduplicate boilerplate in standards. Align standards on conventions, terminology, and data structures. Be a place for concepts used by multiple standards without a good home. Help write clear and readable algorithmic prose by clarifying otherwise ambiguous concepts. Suggestions for more goals welcome. 1. Usage To make use of this standard in a document titled X , use: X depends on Infra . [Infra] Additionally, cross-referencing all terminology is strongly encouraged to avoid ambiguity. 2. Conventions 2.1. Conformance All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. [RFC2119] These keywords have equivalent meaning when written in lowercase and cannot appear in non-normative content. This is a willful violation of RFC 8174, motivated by legibility and a desire to preserve long-standing practice in many non-IETF-published pre-RFC 8174 documents. [RFC8174] All of the above is applicable to both this standard and any document that uses this standard. Documents using this standard are encouraged to limit themselves to "must", "must not", "should", and "may", and to use these in their lowercase form as that is generally considered to be more readable. For non-normative content "strongly encouraged", "strongly discouraged", "encouraged", "discouraged", "can", "cannot", "could", "could not", "might", and "might not" can be used instead. 2.2. Compliance with other specifications In general, specifications interact with and rely on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs require a specification to violate the requirements of other specifications. When this occurs, a document using the should denote such transgressions as a willful violation , and note the reason for that violation. The previous section, § 2.1 Conformance , documents a willful violation of RFC 8174 committed by Infra . 2.3. Terminology The word "or", in cases where both inclusive "or" and exclusive "or" are possible (e.g., "if either width or height is zero"), means an inclusive "or" (implying "or both"), unless it is called out as being exclusive (with "but not both"). A user agent is any software entity that acts on behalf of a user, for example by retrieving and rendering web content and facilitating end user interaction with it. In specifications using the , the user agent is generally an instance of the client software that implements the specification. The client software itself is known as an implementation . A person can use many different user agents in their day-to-day life, including by configuring an implementation to act as several user agents at once, for example by using multiple profiles or the implementation’s private browsing mode. If something is said to be implementation-defined , the particulars of what is said to be implementation-defined are up to the implementation . In the absence of such language, the reverse holds: implementations have to follow the rules laid out in documents using this standard. Insert U+000A (LF) code points into input in an implementation-defined manner such that each resulting line has no more than width code points. For the purposes of this requirement, lines are delimited by the start of input , the end of input , and U+000A (LF). 2.4. Privacy concerns Some features that are defined in documents using the might trade user convenience for a measure of user privacy. In general, due to the internet’s architecture, a user can be distinguished from another by the user’s IP address. IP addresses do not perfectly match to a user; as a user moves from device to device, or from network to network, their IP address will change; similarly, NAT routing, proxy servers, and shared computers enable packets that appear to all come from a single IP address to actually map to multiple users. Technologies such as onion routing can be used to further anonymize requests so that requests from a single user at one node on the internet appear to come from many disparate parts of the network. [RFC791] However, the IP address used for a user’s requests is not the only mechanism by which a user’s requests could be related to each other. Cookies, for example, are designed specifically to enable this, and are the basis of most of the web’s session features that enable you to log into a site with which you have an account. More generally, any kind of cache mechanism or shared state, including but not limited to HSTS, the HTTP cache, grouping of connections, storage APIs, can and ought to be expected to be abused. [COOKIES] [RFC6797] [STORAGE] There are other mechanisms that are more subtle. Certain characteristics of a user’s system can be used to distinguish groups of users from each other. By collecting enough such information, an individual user’s browser’s "digital fingerprint" can be computed, which can be better than an IP address in ascertaining which requests are from the same user. Grouping requests in this manner, especially across multiple sites, can be used for malevolent purposes, e.g., governments combining information such as the person’s home address (determined from the addresses they use when getting driving directions on one site) with their apparent political affiliations (determined by examining the forum sites that they participate in) to determine whether the person should be prevented from voting in an election. Since the malevolent purposes can be remarkably evil, user agent implementors and specification authors are strongly encouraged to minimize leaking information that could be used to fingerprint or track a user. Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit to be derived from exposing APIs that can also be abused for fingerprinting and tracking purposes, so it’s not as easy as blocking all possible leaks. For instance, the ability to log into a site to post under a specific identity requires that the user’s requests be identifiable as all being from the same user, more or less by definition. More subtly, though, information such as how wide text is, which is necessary for many effects that involve drawing text onto a canvas (e.g., any effect that involves drawing a border around the text) also leaks information that can be used to group a user’s requests. (In this case, by potentially exposing, via a brute force search, which fonts a user has installed, information which can vary considerably from user to user.) Features that are defined in documents using the that can be used as a tracking vector are marked as this...