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

[Marc Petit-Huguenin <[e-mail]>]

On 6/15/20 6:09 PM, Scott Morgan wrote:
> Hi All,
> 
>   Thanks for your suggestions!  I am really trying to scope my effort as;
> ***
> How to interpret bytes!
> ***
> ASCII & in particular # 10 seems significant! A single byte that splits
> lines (and could spit other data up);
> https://www.petefreitag.com/item/863.cfm#:~:text=The%20ASCII%20character%20code%2010,a%20line%20in%20a%20file.
> 
> I'm looking to replace JSON & XML as the dominant transfer format for REST
> (and other styles/protocols) that would also be a good standard for
> protocol level information (bits and bytes).

The next logical step in the evolution (or is it devolution?) of XML then JSON is SExp.

> 
> The ASCII newline byte and A8 (intersection of ASCII & UTF-8) seems to be
> logical spit (binary vs character markup data).
> 
> Keep the RFCs coming my way!
> 
> On Mon, Jun 15, 2020 at 1:53 PM Patrick McManus <[e-mail]>
> wrote:
> 
>> you might be interested in structured field values for http
>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/
>>
>> -P
>>
>>
>> On Sat, Jun 13, 2020 at 8:08 AM Stephen McQuistin <
>> [e-mail]> wrote:
>>
>>> Hi Scott,
>>>
>>> We have a draft (draft-mcquistin-augmented-ascii-diagrams) that is
>>> looking to add tooling (e.g., to generate parser code) around “traditional”
>>> packet header diagrams, by using a consistent format for both the diagram
>>> and the text that accompanies it.
>>>
>>> In terms of other PDU description languages, the recent QUIC drafts have
>>> replaced packet diagrams with a bespoke description language:
>>> https://tools.ietf.org/html/draft-ietf-quic-transport-29#section-1.3.
>>>
>>> These are both much simpler than the languages that Marc mentioned, and
>>> only deal with PDU description rather than data layout description more
>>> generally, but might be worth a look.
>>>
>>> Thanks,
>>>
>>> Stephen
>>>
>>> On 13 Jun 2020, at 01:53, Scott Morgan <[e-mail]> wrote:
>>>
>>> Hi Marc,
>>>
>>>    Thanks, I'm not trying to be intentionally confusing :)  In an attempt
>>> to clarify, I'm trying to create a new structured PDU format that could be
>>> used to define PDU description languages (not a primary concern) as well as
>>> larger data structures like files or bytes in datagrams.
>>> https://en.wikipedia.org/wiki/Protocol_data_unit
>>>
>>> Lets continue @ [e-mail] !
>>>
>>> Cheers,
>>> Scott
>>>
>>> ---------- Forwarded message ---------
>>> From: Marc Petit-Huguenin <[e-mail]>
>>> Date: Fri, Jun 12, 2020 at 10:03 AM
>>> Subject: Re: [Webtransport] Standards for protocol headers?
>>> To: Scott Morgan <[e-mail]>, <[e-mail]>
>>>
>>>
>>> Hi Scott,
>>>
>>> I still find your terminology confusing.  I am not sure if you are
>>> proposing to design a new PDU description language (ala ASN.1, ABNF, RBNF,
>>> CDDL, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML,
>>> JSON, CBOR, etc...).  If it is the former, I would suggest to resend your
>>> email to [e-mail], where we discuss this kind of things.
>>>
>>> Thanks.
>>>
>>> On 6/12/20 7:25 AM, Scott Morgan wrote:
>>>> Hi Marc,
>>>>
>>>>    Thanks for responding!  I meant 'protocol header' in the broadest
>>>> sense.  I have implemented some protocols in the past (Web Socket v13,
>>> SMTP
>>>> etc) and work a lot with JSON and XML as I mentioned previously.  Here
>>> are
>>>> some general frustrations (i.e. problem statement) that I'm looking to
>>>> overcome;
>>>>
>>>> 1) JSON and XML generally lack support for binary data (there are some
>>>> workarounds but nothing is super great).
>>>> 2) JSON and XML both now have the concept of a Schema
>>>>          Note I think the concept of a Schema is a good thing but also
>>> feel
>>>> that Schemas often don't cover all
>>>>      Metadata that needs to be covered.  Perhaps the concept of a Schema
>>>> needs to be enhanced by UsageMetadata information.
>>>>          Also note I am frustrated with JSON's inability to provide
>>> human
>>>> readable schemas (multi line text in the .json file (not /n)).
>>>>          I also have frustrations with XML schemas and XML (like
>>> everyone
>>>> else who now favors JSON over XML)
>>>> 3) Protocol's often have Headers and other information which act in a
>>>> similar fashion to Schemas (i.e. they describe / specify data
>>> structures)
>>>>
>>>>   I'm wondering if it's time for a new markup language that can support
>>>> binary data and assist in specifying protocol byte segments in addition
>>> to
>>>> more general purpose transport and storage data (like JSON & XML do).
>>>>   I'm thinking about calling it 'Classification Markup Notation'.
>>>>
>>>>   I messaged this to the group just to throw the idea out there, to get
>>>> feedback and also to find collaborators.
>>>>
>>>>
>>>> On Thu, Jun 11, 2020 at 7:53 AM Marc Petit-Huguenin <
>>> [e-mail]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 6/10/20 5:14 PM, Scott Morgan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>>    I have been working with JSON, XML and some protocol headers
>>> recently
>>>>>> and I am wondering...
>>>>>> Why are there no real standard text formats for protocol headers, or
>>> am I
>>>>>> missing something?
>>>>>>
>>>>>> It seems to me that a slightly more streamlined/optimal binary/markup
>>>>>> standard could help protocols attain POCs and adoption much quicker
>>> and
>>>>>> help reduce some of the work defining protocols.
>>>>>>
>>>>>> Any thoughts on this topic?
>>>>>>
>>>>>>
>>>>>
>>>>> Can you please elaborate on what you mean by "protocol header"?  My
>>>>> understanding of that term is the fixed part at the beginning of a
>>> PDU, PDU
>>>>> that also contains a variable length part after it (as in UDP Header,
>>> TCP
>>>>> Header, RTP Header, HTTP, SIP, SMTP etc...), but that definition does
>>> not
>>>>> seem to apply to JSON or XML (as a whole).
>>>>>
>>>


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug