Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

byte vs base64 format #1310

Closed
hkosova opened this issue Aug 2, 2017 · 7 comments
Closed

byte vs base64 format #1310

hkosova opened this issue Aug 2, 2017 · 7 comments

Comments

@hkosova
Copy link
Contributor

hkosova commented Aug 2, 2017

Data Types defines format: byte as base64-encoded characters.

Considerations for File Uploads and Special Considerations for multipart Content mention format: base64, which is not mentioned in Data Types. Is this a typo and meant to say format: byte? Or are base64 and byte different formats?

@axlbonnet
Copy link

I've stumbled on the same issue and the spec is incoherent on this point.

I've found this remark on the PR that introduces a "base64" that suggests that "byte" is the good format but there was no corrections.

@handrews
Copy link
Member

@hkosova @axlbonnet

JSON Schema draft-07 (which would be relevant to OpenAPI 3.1 at the earliest, possibly 4.0, assuming OAI wants to adopt it at all) adds the contentMediaType and contentEncoding parameters for general support of encoding other forms of data in JSON strings.

These were formerly the type and binaryEncoding keywords within Hyper-Schema's media object, but we do not think JSON Schema users should have to adopt Hyper-Schema for this functionality (or readOnly or writeOnly, both of which are also now in the validation spec).

@pbryan
Copy link

pbryan commented Apr 13, 2018

Where does this leave interpreting "format"? Based on my reading of 3.0.1, it would seem right now that "byte" and "base64" would be synonyms.

@handrews
Copy link
Member

@pbryan in the long run, format should not be used for this. OpenAPI worked around deficiencies in JSON Schema, but I'm hoping we can drop the workarounds and converge on the existing unambiguous solution.

@pbryan
Copy link

pbryan commented Apr 13, 2018

Thanks @handrews.

@hkosova
Copy link
Contributor Author

hkosova commented Mar 5, 2020

Closing in favor of #1547.

@hkosova hkosova closed this as completed Mar 5, 2020
@mma5997
Copy link

mma5997 commented Mar 10, 2021

Hi @hkosova,
we are using the 3.0.0 version currently.
So please can you help me with this query ==> comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants