WebOfTrust
Inconsistent HTTP Content-Type value for CESR requests
We use Content-Type application/json+cesr and application/cesr+json depending on the situation.
- application/json+cesr https://github.com/search?q=repo%3AWebOfTrust%2Fkeripy%20"application%2Fjson%2Bcesr"&type=code,
- application/cesr+json https://github.com/search?q=repo%3AWebOfTrust%2Fkeripy%20"application%2Fcesr%2Bjson"&type=code,
It seems like HTTP responses from "ending", "indirecting" and "oobiing" are set to "application/json+cesr". But requests seem to be send using "application/cesr+json", see https://github.com/WebOfTrust/keripy/blob/b9269018ea144353e14f9ca8ab54609bdb023145/src/keri/app/httping.py#L115 for example.
I believe that application/cesr+json may be more theoretically correct, in the sense that JSON is a specialized form of CESR, but not the other way around. However, from a practical POV, I think any time we communicate IANA content type, we are doing so to signal how the content should be analyzed and understood, and thus we should always use application/json+cesr, on the theory that tools that don't know CESR can still do useful things with the content if they know JSON.
According to the following RFC, our only choice would be application/cesr+json, but we don't believe that applies here because a CESR stream does not have a pure JSON representation. So we believe it should be application/cesr.
https://datatracker.ietf.org/doc/html/rfc6839
This was discussed at the dev call on 07/01/2025
When I said that application/cesr+json is more theoretically, correct, I was saying clumsily what @pfeairheller said much more gracefully and completely. Thanks for clarifying, Phil.
I know that Sam registered the application/cesr content type with IANA, but AFAICT, @SmithSamuelM 's submission has not yet been accepted. It is merely in the provisional registry (https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml), not in the official one (https://www.iana.org/assignments/media-types/media-types.xhtml). There is a note at the top of the provisional registry that says, "This registry, unlike some other provisional IANA registries, is only for temporary use. Entries in this registry are either finalized and moved to the main media types registry or are abandoned and deleted. Entries in this registry are suitable for use for development and test purposes only."
If we cut everything over to use application/cesr, we are thus using something that IANA is not committed to register, and marking the tech as suitable for dev/test purposes, insofar as IANA is concerned. This is regrettable. IANA's opinion may not be the deciding factor here, but I would like the stance vis-a-vis the registry to be stronger, if possible. Is there anything we can do to make it so?
I agree with the point that a CESR stream does not have a pure JSON representation, but using application/json does have the benefit of triggering roughly the correct behavior from web tools like web servers, browsers, CURL, etc. This is a not-insignificant benefit, IMO. I am not making a strong argument that we should lie about the content type -- we should not -- but I am wondering if the discussion (which I missed due to being at a conf in Geneva today) considered whether switching to application/cesr should be accompanied by additional enabling work like providing some help in configuring web servers, modifying the did:webs method to use the proper content type in its .well-known files, etc.?
In my conversations with IANA when I made the provisional registration, the only reason that I know of that is stopping it from becoming a final registration is for us to formally request the provisional become final. I had anticipated that once we finalized the CESR specification at toip and moved it to ISO that we would finalize the CESR IANA registration.
The provisional gives time for anyone who might object to object and since there have been no objections, we just have to formally request.
The hard work is getting the provisional. IANA vets the requesting organization and the provided justification as meeting their minimal standards.
One reason to wait for after formal ToIP and moving to ISO is that it shows IANA that there is a real use case and community backing the registration.
