Downgrading contentEncoding:base64 to 3.0.1: Bug of feature?

[superstas]

Hey there!

I've recently faced an issue with downgrading the Huma-generated OAS spec to 3.0.1.

I have a custom type type MyID uuid.UUID ( where uuid.UUID is google one )

Huma generates a schema that has contentEncoding: base64 for such type in 3.1.0
When downgrading to 3.0.1, it's becoming format: base64.

The problem is that format: base64 is not mentioned in the spec ( I couldn't find it ), and for example, kin-openapi raises an error for such format https://github.com/getkin/kin-openapi/blob/master/openapi3/schema.go#L1017

I looked at it here: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.1.md#data-types

At the same time, there is a migration ( 3.0 -> 3.1 ) guide where this is mentioned as the correct format: https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0 ( from here )

My questions are:

• what is the correct format for contentEncoding: base64 ( in 3.0.* )?
• should it be format: byte, maybe? (here: https://github.com/danielgtaylor/huma/blob/v2.19.0/openapi.go#L1601)

Thank you!

[superstas]

A colleague of mine added some context about the issue.

First of all, format: base64 is a legit format for 3.0.1 (ref)

Also,

format: byte migrated from OAS 2.0 for backward compatibility.
OAS 3.0 introduced format: base64
OAS 3.1 transformed it to contentEncoding:base64
(ref)

However, in OAI/OpenAPI-Specification#3182, format: base64 was explicitly replaced with format: byte, but it's merged to OAS 3.0.4, which is still in dev.

So it looks like using format: base64 for 3.0.1 is ok, not ok for >3.0.1

@danielgtaylor WDYT?