~qeef

~qeef/damn-project

Last active 2 months ago

~qeef/damn-dev

Last active 6 months ago

~qeef/public-inbox

Last active 7 months ago

~qeef/mapathoner

Last active 1 year, 6 months ago
View more

Recent activity

Re: Request for publication of Binary Application Record Encoding (BARE) 16 days ago

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?

Request for publication of Binary Application Record Encoding (BARE) 16 days ago

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

Re: BARE extra proposals 17 days ago

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.

Re: BARE draft 6 feedback 19 days ago

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."?

Re: BARE extra proposals 19 days ago

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}

BARE is close to publication as RFC 24 days ago

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

BARE is close to publication as RFC 24 days ago

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

BARE is close to publication as RFC 24 days ago

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

BARE is close to publication as RFC 24 days ago

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

BARE is close to publication as RFC 24 days ago

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