Rethink the Necessity for base64url Encoding

[sebbader-sap]

It might be the case that the reason for base64url is no longer valid due to the latest changes introduced with V3.0. We need to re-evaluate the necessity of the encoding, or maybe go for a more common and easier pattern, e.g., URL-encoding.

[sebbader-sap]

Following extract of Part 1 and Part 2:

Note 1: to avoid problems with IRI values in URLs, the identifiers shall be base64url-encoded before using them as parameters in the HTTP-APIs. IdshortPaths are base64url-encoded to also allow square brackets.

Note 2: in the example above, “aHR0cHM6Ly9hZG1pbi1zaGVsbC5pby9zYW1wbGVTTQ” is the base64url-encoding of https://admin-shell.io/sampleSM, “sme1.sme2%5B0%5D.p1” is the URL-encoding of “sme1.sme2[0].p1”, and “sme1.sme2%5B0%5D” is the URL-encoding of “sme1.sme2[0]”.

Constraint AASd-130: an attribute with data type "string" shall consist of these characters only: ^[\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD\u00010000-\u0010FFFF]*$.

Constraint AASd-130 ensures that encoding and interoperability between different serializations is possible. It corresponds to the restrictions as defined for the XML Schema 1.031.