Re: [fdt] [Webtransport] Standards for protocol headers?

[Scott Morgan <[e-mail]>]

Hi Again,

  Thanks for responding, I have glanced at these and here are my notes;

https://tools.ietf.org/html/rfc7049
I want to avoid being bound by something like this (i.e. JSON);

The underlying data model is an
   extended version of the JSON data model [RFC4627
<https://tools.ietf.org/html/rfc4627>].


https://tools.ietf.org/html/rfc5234
Yep putting my idea in this form would probably help and be a lot of work.
So far the Bytes Class would simply look like this;
*(OCTET) / *(LF)
Also the LineOfBytes Class would look like this;
*(OCTET) LF
:)

https://www.ietf.org/id/draft-ietf-cellar-ebml-17.txt
This seems similar to what I'm trying to do but different enough to be a
separate idea, I like the part about VINTs.  However since I'm trying to
parse OCTETs distinguishing the 7 bit ascii from other OCTETs I would need
(7 bit VINTs) to allow for that compression.

Please let me know if anyone is interested in collaborating on this idea!

On Tue, Jun 23, 2020 at 11:56 PM Carsten Bormann <[e-mail]> wrote:

> On 2020-06-24, at 04:27, Scott Morgan <[e-mail]> wrote:
> >
> > Thoughts?
>
> Well, you seem to want to invent another lexical syntax.
>
> 2020, we don’t do that any more.
>
> For things that are text and need to be exchanged as text, JSON is the
> lexical syntax now.
> Where you need more flexibility (e.g., include JPEG) and don’t have a need
> for the encoding to be text, use CBOR.
>
> This turns the question “what is the lexical syntax” (something which you
> would express in ABNF) into the question “what is the structure of the
> data” (something that you express in CDDL).  For a theoretician, of course,
> both are syntaxes, but there is a lot of benefit in handling the lexical
> syntax with a known good software component (many bugs that turn into
> attack vectors are in parsers for lexical syntax).
>
> [That doesn’t mean you cannot have fatal bugs in the component that
> handles the structure of the data — we have just reduced the attack surface
> a lot, and we can use an optimized component for the lexical work.]
>
> This doesn’t mean there isn’t a place for highly refined encodings such as
> HDF5, or legacy structural encodings such as RIFF (underlying WAV etc.) or
> JPEG’s byte stuffing based delimiters.  There are even new legacy encodings
> of this kind being defined :-) (e.g., Extensible Binary Meta Language,
> draft-ietf-cellar-ebml).  But for 98 % of all new work, JSON and CBOR are
> it.
>
> Grüße, Carsten
>
>

-- 
Regards,
Scott Morgan
President & CEO
Adligo Inc
http://www.adligo.com
https://www.linkedin.com/in/scott-morgan-21739415
A+ Better Business Bureau Rating
<https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256>
https://github.com/adligo

By Appointment Only:
1-866-968-1893 Ex 101
[e-mail]
skype:adligo1?call
Send Me Files Securely:
*https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI
<https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>*