Carsten:
The way i see it, the underlying issue seems to be that most IETF specs that
use JSON seem to be happy in specifying their JSON objects without formal
specification of their JSON objects in CDDL.
For example, i walk through the list of drafts/RFCs referencing RFC7515
(JSON Web Signatures), pick random documents and look for CDDL or other
formal specs of the JSON objects. And i at least didn't find any. Of course,
there may be some, but i would be surprised if we had an actually adoped
practice that says "RFCs that specify JSON structures MUST use a formal
language such as CDDL to define them".
> > "payload": BASE64URL(ietf-voucher:voucher),
> I don’t know what ietf is, from which voucher:voucher is subtracted; can’t
> even parse the : without a ? around.
You're too fast. I stilll need to understand this rfc791 spec from 1981:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
I still have not figured out how to add and subtract all those numbers.
I think the result must be 42 though.
Aka: we do have a pretty successful history with make-it-up-as-you-go
(in)formal specifications. And i think such BASE64URL format
falls well into that domain. Of course, we do want to make these as
self-explanatory and self-descriptive as possible and add explanatory text
where they're not.
Cheers
toerless
On Wed, Jul 19, 2023 at 08:56:05AM +0200, Carsten Bormann wrote:
> On 18. Jul 2023, at 17:38, Michael Richardson <[email protected]> wrote:
> >
> >
> > In the JWS I-D, we have some JSON that is an example.
> > And the content within is BASE64URL encoded.
> > We could, I think, describe this in CDDL, but we aren't trying to be
> > authoritative. (It's a JOSE example)
>
> OK, CDDL describes possible sentences in the language, while you seem to be
> trying to express a single example, with input parameters and some processing.
Right. the actual
>
> CBOR diagnostic notation is getting some features for application-specific
> literals, but so far we didn’t really make it compute (or take parameters).
> We could try to import CDDL operators for the compute.
> (And describe how to use CBOR diagnostic notation to compute JSON, but that
> is trivial given Section 6.1 of RFC 8949.)
>
> > We are struggling with quoting. We could write:
> >
> > "payload": "BASE64URL(ietf-voucher:voucher)",
>
> Well, what is the point of the example?
> If it is only for illustration, this would work with some text added about
> what this means.
> If it is intended to specify the outcome, we would need some of the above.
>
> > which would make it valid JSON, with the literal contents.
>
> Yes, so you could validate it as JSON, but then the literal contents really
> are a misrepresentation.
> (If validation is about catching missing commas, this is still useful.)
>
> > Or we could write:
> >
> > "payload": BASE64URL(ietf-voucher:voucher),
>
> Which one could no longer parse, and there would be no meaning right now
> except as pseudocode.
>
> > which sorta makes it valid Javascript, assuming such a function existed.
>
> I don’t know what ietf is, from which voucher:voucher is subtracted; can’t
> even parse the : without a ? around.
>
> > here is an example with both variations:
> >
> > {
> > "payload": BASE64URL(ietf-voucher:voucher),
> > "signatures": [
> > {
> > "protected": "BASE64URL(UTF8(JWS Protected Header))",
> > "signature": "base64encodedvalue=="
> > }
> > ]
> > }
>
> What is UTF8()? Do you mean the equivalent of JSON.stringify?
>
> I summary, these “recipes” are interesting, and we have some 90 % of what we
> need.
> Maybe we can have a short brainstorming session at IETF 117 Hackathon.
>
> Grüße, Carsten
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
