From 1a5aa3a98ee787d1c20c6ea5d112ff8ed685905b Mon Sep 17 00:00:00 2001 From: Micke Nordin Date: Tue, 17 Feb 2026 11:52:24 +0100 Subject: [PATCH] Fix ASCII art diagrams in Appendix D being mangled in text output Remove the 'artwork' info string from fenced code blocks so kramdown-rfc produces elements instead of or , which collapsed the diagrams into single lines. --- IETF-RFC.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 14f2dde..5acef37 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -1593,7 +1593,7 @@ flow or direct entry. It provides a convenient way for users to organize and access their federated contacts, and MAY allow users to generate _Invites_. -~~~ artwork +~~~ +-----------------+ | Address Book | | | @@ -1627,7 +1627,7 @@ created through the Invite process or via direct entry. A Contact MAY of course contain much more detailed information about the referenced user such as if it was added via _Invites_ or direct entry. -~~~ artwork +~~~ +-----------------+ | Contact | +-----------------+ @@ -1663,7 +1663,7 @@ The Invite entity represents the bidirectional trust establishment mechanism in OCM. It facilitates secure contact exchange between users on different OCM Servers. -~~~ artwork +~~~ +-----------------+ | Invite | +-----------------+ @@ -1703,7 +1703,7 @@ implementor might find it useful to have a Provider object model to store the discovered information about federation peers or other remote OCM Providers. -~~~ artwork +~~~ +-----------------------+ | Provider | | (OCM Server) | @@ -1760,7 +1760,7 @@ The Share entity represents a policy granting access to a _Resource_ from a Sending Party to a Receiving Party. -~~~ artwork +~~~ +-----------------+ +------------------+ | Sending Party | | Receiving Party | +-----------------+ +------------------+ @@ -1822,7 +1822,7 @@ from a Sending Party to a Receiving Party. The User entity represents the party in OCM who can send and receive Shares and Invites and manage Contacts, and interact with Resources. -~~~ artwork +~~~ +-----------------------+ | User | +-----------------------+ @@ -1874,7 +1874,7 @@ Receiving Party through the Sending Server's API. In general a Resource is a much more complex entity, but for the purpose of OCM we only need to model a few key properties. -~~~ artwork +~~~ +-----------------+ | Resource | +-----------------+