]> The Restatement Anti-Pattern Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org
Normative documents that cite other normative documents often restate normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction Normative documents that cite other normative documents often restate normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern , and how it can be mitigated.
Conventions and Definitions Although this document is not an IETF Standards Track publication, it adopts the conventions for normative language to provide clarity of instructions to the implementer. 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 Restatement Anti-Pattern A Restatement is the attempted expression of information that is already expressed elsewhere. In this document, we are mostly concerned with Normative Restatements, i.e., statements that are intended (or look like they are intended!) to be normative. Restatements are rarely verbatim copies of the original statement and the context needed to interpret that, so they tend to introduce uncertainty about the interpretation of the restatement. Authors often presume a reader is well-versed enough to infer that such an uncertainty (or outright contradiction) is not intended and how it is to be resolved. There is little reason to believe this is actually the case. An internal restatement is a restatement of information that has been provided previously in the document under discussion. Note that an unambiguous internal reference is not a restatement, as it points to the original text and its context. (There may still be uncertainties how to interpret the internal restatement in the additional context.) A reference is unambiguous if the previous passage is clearly identified and delimited. An external restatement is a restatement of information that has been provided in (one or more) external documents. Here there is increased danger of an unclear scope of the reference, often by pointing to an entire document where only a specific passage is actually intended to be referenced. Restatements can be entirely hidden, i.e., there is no indication that information given is a restatement. Restatements can also be explicit by clearly being identified as such, typically no longer using normative language. Restatements can be an Anti-Pattern because they can be "a common response to a recurring problem that is usually ineffective and risks being highly counterproductive" . discusses the recurring problems as perceived by document authors, explains why restatements can be ineffective and counterproductive, and discusses how to use restatements in a way that is not.
Reasons for making restatements There are many reasons that cause document authors to include restatements in their work, many of which are actually good reasons once the perils of restatements are properly managed.
Integrating a Complicated Base Standard Ecosystem Sometimes the source of the actual normative statement is complex and would require considerable time to digest. A simplifying restatement tries to shield the reader by rephrasing or summarizing information from that source. Such a restatement can be of good intention, or it can try to hide complexity that the referencing document actually does make required to incur.
Trying to be a Textbook for the Implementer More generally, a restatement can attempt to be a directly useful source for an implementer or user of a standard, e.g., by giving a mere checklist of items (not necessarily complete!) that must be implemented instead of actually identifying where the requirement and possibly its finer points come from.
Increasing Availability from a Source with Restricted Access In some cases, normative information from a cited document is not openly available, but only under specific conditions that cannot be expected to be satisfied by all users of the referencing document, such as membership in an organization or payment of a non-trivial fee. It may be appropriate to restate information from such a source so the referencing document becomes useful.
Trying to Raise Attention to a Detail Deemed Surprising The author of the referencing document may see a need to alert the reader to a detail of the cited document that might seem unintuitive (i.e., not familiar) to the author. By restating the detail in terms more familiar to readers of the referencing document, this alert can be more useful.
Bad formal description techniques Formal description techniques (FDT, such as ABNF) are usually designed to document a single specific artifact, not its evolution or its embedding into another artifact. This can lead to wholesale imports of FDT material, without indication whether just the FDT was imported or whether the importing document is intended to evolve with the donor document. See and for additional illustration of this reason.
Perils of restatements The danger of restatements is that they might not be exactly expressing the same normative statement that the cited document makes. One form of this is the incomplete restatement. Abridged copies of a normative statement from the cited document often leave open whether the abridgment is intentional: Is the referencing document only importing some of the requirements of the cited document? In the worst case, the restatement may appear to be forking an ecosystem, i.e., an implementation of the cited document cannot be used because it makes additional constraints that are not meant to be included in the referencing document. (This peril of course is also present with intentional changes to the normative statements in a cited document, but is likely to receive much more attention during review.) presents an example for the situation where a reader might infer behavior based on the common law statute interpretation rule:
  • "Expressio unius est exclusio alterius"
which states that the reader is to presume that expressly referencing one matter implies that other similar matters are intentionally not mentioned and therefore are excluded. This is particularly problematic with abridged statements, where this rule may be invoked by the reader without an author being aware of it. Restatements may be slightly semantically different from the cited document, in particular if the latter is based on a relatively inaccessible (possibly poorly documented or poorly developed) terminology. Both authors and readers may not be aware that they need to use tools that are commonplace in the ecosystem of the cited document. A large danger originates from restatements that are unclear whether a new normative requirement is intended or a just a restatement of known normative requirements of the cited document. This is, of course, particularly dangerous for hidden restatements. A restatement can cause maintainability hazards, as illustrated in ; it also can cause a referencing document to decouple from the ecosystem of a cited document once that is repaired (). Finally, to readers familiar with the cited document, the restatement can be surprising; if there really is no information in the restatement, the reader automatically searches for a specific reason this restatement is made and starts to reinterpret it until it means something specific that would justify its presence. If the restatement is not clearly identified as such, this is likely to cause misinterpretations, as if the usage envisioned attempts to fork the cited ecosystem. (Often, the people who need to interpret the document in question are actually more familiar with the cited document and the surrounding ecosystem than the authors of the referencing document, who may just be pulling in the ecosystem to solve one of their problems.)
Defusing restatements A general recommendation for readers of a referencing document is that they should try to detect restatements and read them in full knowledge of their perils (). If a resolution is required, the RFC errata process may provide a (poor) mechanism to obtain the resolution and ensure it is documented in the context of the referencing document. Mailing list discussions are also a good way to obtain a resolution, but for additional readers they can be hard to find, and, when found, it can be hard to extract any consensus that was formed. The rest of this section provides a summary of the recommendations made by this document, employing keywords as an instruction to the potential implementers of this document, i.e., document authors and reviewers. Much of the danger of restatements can be averted if they are sufficiently identified by the authors as such.
  • For identification of internal restatements, use phrases such as: In other words, hence, in particular, as discussed in Section NN.
  • For identification of external restatements: As described/defined in ...
  • In both cases, make sure that any local reference is clear and any non-local reference is resolvable and well-scoped.
  • Rephrasing the statement as a Note can make clear that there is no normative intention.
  • Examples MUST be identified clearly as such, including identifying any explanatory notes as such so that these are not misunderstood as new normative statements.
If a larger copy from a cited document is made, it SHOULD be made verbatim and differences introduced deliberately should be explicitly identified, possibly in a second step. Note that the FDT mechanisms and their evolution can make verbatim copies less useful, in which case a systematic approach of first copying and fixing and then, if necessary, modifying can help the reader. For instance, uses a variant form of ABNF that can be parsed only once the variant ":=" syntax is replaced by "=". (This is an active specification and was cited as recently as in , which provides a clearly identified restatement in modern ABNF, with errata applied and rules referenced from elsewhere added [we ignore the innocuous redefinition of "hex" from "HEXDIG"].) By making the copy informative, repairs from the base document (in the example e.g. ) can be imported, even future ones. Where the copy is made because the cited document is not openly available, this also often requires more processing than a verbatim copy, increasing the probability of introducing errors and misunderstandings. This can be somewhat mitigated by clearly stating the purpose of a restatement, and the intended result when the restatement and the original diverge.
Summary of Recommendations (...Add nice checklist text for authors and reviewers based on later...)
Examples
Example: Web linking This example is about an internal, FDT-induced restatement in , which turned into an external restatement in , which was not healed by the update to in . defines a serialization of web links in a Link Header Field. A link can have zero of more link-param parameters, each of which has the form (simplified): So link-extensions can always be written as a quoted-string, or, alternatively, without quotes as a ptoken if the more limited character repertoire of ptokens suffices. However, also defines the specifics of a few link parameters. When simply inserting this into the overall ABNF, the ABNF given for these link parameters needs to restate the ABNF for link parameters in their common syntax (simplified): URI-Reference <"> ) / ( "rev" "=" relation-types ) / ( "hreflang" "=" Language-Tag ) / ( "media" "=" ( MediaDesc / ( <"> MediaDesc <"> ) ) ) / ( "title" "=" quoted-string ) / ( "type" "=" ( media-type / quoted-mt ) ) ]]> This restatement loses the intended choice between ptoken and quoted-string for many predefined link parameters, only keeping it for "media" and "type" (and "rel" in the definition of relation-types, which is arguably faulty by allowing non-ptoken characters in an unquoted URI). One could say that this restatement was caused by a limitation of ABNF: ABNF cannot separately express both the overall syntax of link-params (which yields the link-param value)) and the specific syntax for the predefined link-params, contaminating the former with the latter. The specific syntax would really need to be in terms of the value yielded as opposed to restating the link-param syntax that yields the value. finally repairs this:
Note that any link-param can be generated with values using either the token or the quoted-string syntax; therefore, recipients MUST be able to parse both forms. In other words, the following parameters are equivalent: Previous definitions of the Link header did not equate the token and quoted-string forms explicitly; the title parameter was always quoted, and the hreflang parameter was always a token. Senders wishing to maximize interoperability will send them in those forms. Individual link-params specify their syntax in terms of the value after any necessary unquoting (as per ).
Unfortunately, adds an external restatement copying from in defining a few more link-params (simplified): The letter of this specification for instance prohibits sz="47" (requiring this to be represented as sz=47). The repair in cannot quite fix this as:
  • it is not clear that the repair actually applies to (a general problem with updated ["obsoleted"] references)
  • the ABNF in would need to be rewritten to apply the rule cardinal to the extracted value of the link-param.
Example: Restatement of in was largely intended as a freely available restatement of the paywalled , with focus added on formally defining the parts that might be useful in the Internet. However, when introduced additional text that seemed to disallow the syntax used for one extension that had made to the semantics of , the precedence remained unclear. Implementers of Internet-related standards largely ignored the additional semantics of that extension anyway, while implementers of in general often performed input validation that made sure the extension made by wouldn't work. (This is only now being addressed by .)
Example: Date-Time in YANG (RFC6991) defines a YANG type date-and-time on page 11, restating parts of (the restatement is also faulty in its item (b), with an attempted cleanup in ). Now that is being bug-fixed via , it is not clear whether the change applies to the YANG type as well. This is more of a problem for YANG than it might be otherwise, as it might trigger the YANG concept of a "non-backwards-compatible" change to that datatype — a problem that is not entirely caused by restatements but gets much harder to discuss.
Example: ACME for Subdomains (RFC9444-to-be) RFC9444-to-be defines a new feature added to , referencing the base standard in a number of places. Reviewing the draft , states:
  • ## restatement vs. new normative content Providing a specification of a new feature added to ACME, the text explains a number basic ACME mechanisms that are relevant to this specification. One pervasive problem is that these restatements of RFC 8555 content are not always easy to distinguish from new, normative statements made by this document. E.g., 4.2 contains a statement about "is defined" that is part of a paragraph restating RFC 8555 -- this one, however, appears to be new normative content. (Languagetool diagnoses overuse of passive voice, which exacerbates this problem.) (The first paragraph of section 4 repeats the last paragraph of section 3. But that is not a problem; redundancy can be good if it improves the flow, and this is clearly labeled as a restatement.) The introduction of section 4 is a summary/restatement of RFC 8555; section 4.1 introduces new normative content without warning (and leads the reader astray by actually referencing RFC 8555).
(These problems were addressed in a later draft of RFC9444-to-be.)
Example: Base64 Encoding variants in draft-ietf-rats-eat-20 Base64 encoding is defined in , but comes in a number of variants. These often have default settings that are to be used "unless the specification referring to this document explicitly states otherwise" (e.g., ). Documents that reference normatively are surprisingly often sloppy in doing so. Not : Its Section 2 (terminology) defines the term "Base64url Encoding”, referencing as well as to fill in the open questions from (i.e., Section 5 and not Section 4, no '=' padding that would be default, no extra characters). While this was a good start, incomplete restatements in the following text cause a problem :
A term "base64url encoded” [...] is used in multiple places. One of the places restates its own reference to RFC 4648, but doesn’t restate the reference to RFC 7515 and the text required with that. This restatement is very misleading as it strongly implies RFC 7515 is not used here; the reference needs to be removed. In the other places I find the term is simply used, which assumes the reader will think to look up the term in the terminology [...]
(The problem in the draft was quickly addressed in the next revision.)
Security Considerations Restatements about security requirements and properties can create the same uncertainties and interoperability problems as restatements in other contexts. Security considerations sections have turned out to be an attractor for such problems. They are meant "both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues" . In practice, they tend to be the first point in a document that security issues are considered at all, so they often both contain normative statements that are nowhere else in the document and security-conscious restatements of other normative statements in the document, the latter with all the perils that this memo is about. The fact that security considerations sections are often heavily fleshed out during IESG processing can exacerbate the problem.
IANA Considerations This document has no IANA actions.
References Normative References Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Patterns and Antipatterns Anti Pattern C2 Wiki (Last edited:) Anti-pattern Wikipedia page (at the time of writing:) Guidelines for Writing RFC Text on Security Considerations All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The "data" URL scheme A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK] RFC Errata Report » RFC Editor n.d. search result Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFCs 3709 and 6170. Web Linking This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK] Constrained RESTful Environments (CoRE) Link Format This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] Web Linking This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JSON Web Signature (JWS) JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. Common YANG Data Types This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. Common YANG Data Types Constructor University This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Date and Time on the Internet: Timestamps with additional information Igalia, S.L. Universität Bremen TZI This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone. It updates RFC3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see Section 2. // (This "cref" paragraph will be removed by the RFC editor:) The // present version (-09) addresses comments received during IETF last // call. The Entity Attestation Token (EAT) Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Re: [Rats] I-D Action: draft-ietf-rats-eat-20.txt n.d. Automatic Certificate Management Environment (ACME) Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. ACME for Subdomains Cisco Cisco DigiCert Sandelman Software Works This document outlines how ACME can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. The client has fulfilled a challenge against a parent domain but does not need to fulfill a challenge against the explicit subdomain as certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. [Last-Call] Artart last call review of draft-ietf-acme-subdomains-04 Data elements and interchange formats — Information interchange — Representation of dates and times International Organization for Standardization Also available from <⁠https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf>. Data elements and interchange formats — Information interchange — Representation of dates and times International Organization for Standardization
Acknowledgments Julian Reschke opened the author's eyes to the fundamental problem of restatements, possibly not using this word. Many IETFers over decades have worked on mitigating restatements; the author apologizes that examples in this memo naturally mainly come from the author's own recollection.