Line brakes

Author: mickenordin

IETF-RFC.md

@@ -124,7 +124,8 @@ related concepts from OAuth [RFC6749] and elsewhere:
     Resource through an API (e.g., WebDAV [RFC4918]) of the sending
     server.
 * __Sending Gesture__ - A user interface interaction from the Sending
-  Party to the Sending Server, conveying the intention to create a Share.
+  Party to the Sending Server, conveying the intention to create a
+  Share.
 * __Share Creation__ - The addition of a Share to the database state of
   the Sending Server, in response to a successful Sending Gesture or for
   another reason.
@@ -143,9 +144,9 @@ related concepts from OAuth [RFC6749] and elsewhere:
   identify a user or group "at" an OCM Server and MAY be referred to as
   Federated Cloud ID.
   `<Receiving Party's identifier>` is an opaque string, unique at the
-  server.  `<fqdn>` is the Fully Qualified Domain Name by which the server
-  is identified.  This MUST be the domain at which the `/.well-known/ocm`
-  endpoint of that server is hosted.
+  server.  `<fqdn>` is the Fully Qualified Domain Name by which the
+  server is identified.  This MUST be the domain at which the
+  `/.well-known/ocm` endpoint of that server is hosted.
 * __OCM Notification__ - A message from the Receiving Server to the
   Sending Server or vice versa, using the OCM Notifications endpoint.
 * __Invite Message__ - Out-of-band message used to establish contact
@@ -165,17 +166,18 @@ related concepts from OAuth [RFC6749] and elsewhere:
   generated by the Invite Sender OCM Server and linked uniquely to the
   Invite Sender's OCM Address.
 * __Invite Creation Gesture__ - Gesture from the Invite Sender to the
-  Invite Sender OCM Server, resulting in the creation of an Invite Token.
+  Invite Sender OCM Server, resulting in the creation of an Invite
+  Token.
 * __Invite Acceptance Gesture__ - Gesture from the Invite Receiver to
   the Invite Receiver OCM Server, supplying the Invite Token as well as
   the OCM Address of the Invite Sender, effectively allowlisting the
   Invite Sender OCM Server for sending Share Creation Notifications to
   the Invite Receiver OCM Server.
 * __Invite Acceptance Request__ - API call from the Invite Receiver OCM
   Server to the Invite Sender OCM Server, supplying the Invite Token as
-  well as the OCM Address of the Invite Receiver, effectively allowlisting
-  the Invite Sender OCM Server for sending Share Creation Notifications to
-  the Invite Receiver OCM Server.
+  well as the OCM Address of the Invite Receiver, effectively
+  allowlisting the Invite Sender OCM Server for sending Share Creation
+  Notifications to the Invite Receiver OCM Server.
 * __Invite Acceptance Response__ - HTTP response to the Invite
   Acceptance Request.
 * __Share Name__ - A human-readable string, provided by the Sending
@@ -347,8 +349,8 @@ The Invite Acceptance Response SHOULD be a HTTP response:
   - REQUIRED: `userID` - the Invite Sender's identifier at their OCM
     Server
   - REQUIRED: `email` - non-normative / informational; an email address
-    for the Invite Sender.  Not necessarily at the same FQDN as their OCM
-    Server
+    for the Invite Sender.  Not necessarily at the same FQDN as their
+    OCM Server
   - REQUIRED: `name` - human-readable name of the Invite Sender, as a
     suggestion for display in the Invite Receiver's address book
 
@@ -511,8 +513,8 @@ contain the following information about its OCM API:
   endpoint.  Example: `"MyCloudStorage"`
 * REQUIRED: resourceTypes (array) - A list of all resource types this
   server supports in both the Sending Server role and the Receiving
-  Server role, with their access protocols.  Each item in this list SHOULD
-  itself be an object containing the following fields:
+  Server role, with their access protocols.  Each item in this list
+  SHOULD itself be an object containing the following fields:
   - name (string) - A supported resource type (file, calendar,
     contact, ...).
     Implementations MUST offer support for at least one
@@ -618,7 +620,8 @@ contain the following information about its OCM API:
   enhance the UX of the Invite Flow.  If for example
   `"/index.php/apps/sciencemesh/accept"` is specified here then a WAYF
   Page SHOULD redirect the end-user to
-  `/index.php/apps/sciencemesh/accept?token=zi5kooKu3ivohr9a&providerDomain=example.com`.
+  `/index.php/apps/sciencemesh/accept?token=zi5kooKu3ivohr9a&providerDomain=example.com`
+  .
 
 # Share Creation Notification
 
@@ -740,8 +743,8 @@ servers MAY only support `webdav`.
     Resource.
   - OPTIONAL requirements (array of strings) -
     The requirements that the sharee MUST fulfill to
-    access the Resource.  A subset of: - `mfa-enforced` requires the consumer to be
-    MFA-authenticated.  This MAY be used if the
+    access the Resource.  A subset of: - `mfa-enforced` requires the
+    consumer to be MFA-authenticated.  This MAY be used if the
     recipient provider exposes the `enforce-mfa`
     capability.  - `use-code` requires the consumer to exchange
     the given `code` via a signed HTTPS request.  This
@@ -756,10 +759,10 @@ servers MAY only support `webdav`.
     the `/.well-known/ocm` endpoint MUST be used.
     Absolute URIs are deprecated.
   - REQUIRED viewMode (string)
-    The permissions granted to the sharee.  A subset of: - `view` allows access to the web app in view-only
-    mode.  - `read` allows read and download access via the
-    web app.  - `write` allows full editing rights via the web
-    app.
+    The permissions granted to the sharee.  A subset of: - `view`
+    allows access to the web app in view-only mode.  - `read` allows
+    read and download access via the web app.  - `write` allows full
+    editing rights via the web app.
   - OPTIONAL sharedSecret (string)
     An optional secret to be used to access the remote
     web app, for example in the form of a bearer token.
@@ -880,16 +883,17 @@ is as follows:
 1.  The receiver MUST extract the OCM Server FQDN from the `sender`
     field of the received share, and MUST query the
     [Discovery](#ocm-api-discovery) endpoint at that address: the
-    `resourceTypes[0].protocols.webdav` value is the `<sender-ocm-path>` to
-    be used in step 3.
+    `resourceTypes[0].protocols.webdav` value is the
+    `<sender-ocm-path>` to be used in step 3.
 2.  If `code` is not empty, the receiver SHOULD make a signed POST
     request to the `/token` path inside the Sending Server's OCM API, to
     exchange the code for a short-lived bearer token, and then use that
     bearer token to access the Resource.
 3.  If `protocol.name` = `webdav`, the receiver SHOULD inspect the
     `protocol.options` property.  If it contains a `sharedSecret`, as in
-    the [legacy
-    example](https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post),
+    the [legacy example](
+    https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post
+    ),
     then the receiver SHOULD make a HTTP PROPFIND request to
     `https://<sharedSecret>:@<sender-host><sender-ocm-path>`.  Note that
     this access method, based on Basic Auth, is _deprecated_ and may be
@@ -899,11 +903,11 @@ is as follows:
     receiver MUST make a HTTP PROPFIND request against it to access the
     Remote Resource.  If it only contains an identifier `<key>`, the
     receiver MUST make a HTTP PROPFIND request to
-    `https://<sender-host><sender-ocm-path>/<key>` in order to access the
-    Remote Resource.  Additionally, the receiver MUST pass an
-    `Authorization: bearer` header with either the short-lived bearer token
-    obtained in step 2, if applicable, or the `protocol.webdav.sharedSecret`
-    value.
+    `https://<sender-host><sender-ocm-path>/<key>` in order to access
+    the Remote Resource.  Additionally, the receiver MUST pass an
+    `Authorization: bearer` header with either the short-lived bearer
+    token obtained in step 2, if applicable, or the
+    `protocol.webdav.sharedSecret` value.
 
 In all cases, in case the Shared Resource is a folder and the Receiving
 Server accesses a Resource within that shared folder, it SHOULD append
@@ -985,14 +989,16 @@ Implementers SHOULD NOT use it and prefer short-lived tokens instead.
 
 ## Normative References
 
-[RFC2119] Bradner, S. "[Key words for use in RFCs to Indicate Requirement
-Levels](https://datatracker.ietf.org/doc/html/rfc2119)", March 1997.
+[RFC2119] Bradner, S. "[Key words for use in RFCs to Indicate
+Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119)",
+March 1997.
 
-[RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed Authoring
-and Versioning](https://datatracker.ietf.org/html/rfc4918/)", June 2007.
+[RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed
+Authoring and Versioning](https://datatracker.ietf.org/html/rfc4918/)",
+June 2007.
 
-[RFC8174] Leiba, B. "[Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
-Words](https://datatracker.ietf.org/html/rfc8174)", May 2017.
+[RFC8174] Leiba, B. "[Ambiguity of Uppercase vs Lowercase in RFC 2119
+Key Words](https://datatracker.ietf.org/html/rfc8174)", May 2017.
 
 [RFC9421] Backman, A., Richer, J. and Sporny, M. "[HTTP Message
 Signatures](https://tools.ietf.org/html/rfc9421)", February 2024.
@@ -1073,8 +1079,8 @@ Here is an example of headers needed to sign a request.
     signature
   - 'signature' the signature of an array containing the properties
     listed in 'headers'.  Some properties like content-length, date,
-    content-digest, and host are mandatory to protect against authenticity
-    override.
+    content-digest, and host are mandatory to protect against
+    authenticity override.
 
 ## How to generate the Signature for outgoing request