From Jiri Vlasak to ~sircmpwn/public-inbox
Dear Eliot, > The independent stream is specifically *prohibited* from producing > standards. thank you for your clarification. Based on your feedback, I think I should go for the IETF standardization process. > * If you would like to consider using the IETF process, I can put you > in touch with the DISPATCH chairs and the area directors, just so > that they can assist you in getting the ball rolling. That would be great, thank you. Is it ok to send an email to the art@ietf.org mailing list asking for comments as a first step?
From Jiri Vlasak to ~sircmpwn/public-inbox
Dear Independent Submissions Editor, I would like to ask you to consider publishing Binary Application Record Encoding (BARE). If you have any questions, please feel free to contact me or the CC mailing list. Below is the requested information from the submission [1]: > The filename of the published internet draft that is being submitted. draft-devault-bare-07.xml [2]. > The desired category (Informational or Experimental) of the RFC. Informational
From Jiri Vlasak to ~sircmpwn/public-inbox
> > I'm not sure why is that. Wouldn't this disallow used-in-the-future > > types? An example: > > > > type Nowadays void > > type Future void > > type Msg union {Nowadays} > > Yes this disables this schema. > This is a kind of unused type. > > IMO void should always be used (in at least one union). I'm afraid this could complicate debugging. I can imagine situation when you want to disable/change some type temporarily.
From Jiri Vlasak to ~sircmpwn/public-inbox
> The following syntax is confusing: > > > Signed integers are represented as uint using a "zig-zag" encoding: > > positive values x are written as 2x + 0, negative values are written > > as 2(^x) + 1. > > What does the '^' symbol mean? (and should I feel stupid for asking > this question?) It's explained in the following sentence. No, you shouldn't, it should be clear from the first sentence. > Would it not be better to say > "negative values are written as -2x - 1."?
From Jiri Vlasak to ~sircmpwn/public-inbox
> void types are already well constrained since they are only allowed in > tagged unions. > > I would like to add an extra invariant: > > A type that is ultimately a void type (either directly or via a > user-defined type) MUST be used by at least one tagged union. I'm not sure why is that. Wouldn't this disallow used-in-the-future types? An example: type Nowadays void type Future void type Msg union {Nowadays}
From Jiri Vlasak to ~alva/zig-bare
Dear authors of BARE implementation, we have finished the review of Binary Application Record Encoding (BARE) Internet Draft [1][2] before requesting the publication. We welcome the feedback for the latest version of the draft [3]. The next step is publication request to Independent Submissions Editor that is planned for the next week, May 11. Please, let me know if you plan to review the RFC I-D and need more time. I'll prolong the publication request date. [1]: https://datatracker.ietf.org/doc/draft-devault-bare/ [2]: https://baremessages.org/ [3]: https://www.ietf.org/archive/id/draft-devault-bare-06.html
From Jiri Vlasak to ~tdeo/serde_bare
Dear authors of BARE implementation, we have finished the review of Binary Application Record Encoding (BARE) Internet Draft [1][2] before requesting the publication. We welcome the feedback for the latest version of the draft [3]. The next step is publication request to Independent Submissions Editor that is planned for the next week, May 11. Please, let me know if you plan to review the RFC I-D and need more time. I'll prolong the publication request date. [1]: https://datatracker.ietf.org/doc/draft-devault-bare/ [2]: https://baremessages.org/ [3]: https://www.ietf.org/archive/id/draft-devault-bare-06.html
From Jiri Vlasak to ~chiefnoah/inbox
Dear chiefnoah, we have finished the review of Binary Application Record Encoding (BARE) Internet Draft [1][2] before requesting the publication. We welcome the feedback for the latest version of the draft [3]. The next step is publication request to Independent Submissions Editor that is planned for the next week, May 11. Please, let me know if you plan to review the RFC I-D and need more time. I'll prolong the publication request date. [1]: https://datatracker.ietf.org/doc/draft-devault-bare/ [2]: https://baremessages.org/ [3]: https://www.ietf.org/archive/id/draft-devault-bare-06.html
From Jiri Vlasak to ~martijnbraam/public-inbox
Dear Martijn, we have finished the review of Binary Application Record Encoding (BARE) Internet Draft [1][2] before requesting the publication. We welcome the feedback for the latest version of the draft [3]. The next step is publication request to Independent Submissions Editor that is planned for the next week, May 11. Please, let me know if you plan to review the RFC I-D and need more time. I'll prolong the publication request date. [1]: https://datatracker.ietf.org/doc/draft-devault-bare/ [2]: https://baremessages.org/ [3]: https://www.ietf.org/archive/id/draft-devault-bare-06.html
From Jiri Vlasak to ~earboxer/public-inbox
Dear Zach, we have finished the review of Binary Application Record Encoding (BARE) Internet Draft [1][2] before requesting the publication. We welcome the feedback for the latest version of the draft [3]. The next step is publication request to Independent Submissions Editor that is planned for the next week, May 11. Please, let me know if you plan to review the RFC I-D and need more time. I'll prolong the publication request date. [1]: https://datatracker.ietf.org/doc/draft-devault-bare/ [2]: https://baremessages.org/ [3]: https://www.ietf.org/archive/id/draft-devault-bare-06.html