I'm wondering if there's any desire to further the BARE draft RFC through the process of
getting properly standardized. It's been awhile since I've read through the process, so
I'm not sure if the existing draft can be unarchived, but I'm interested in reviving
this and trying to push it through. I figured I would check in here first, especially as
it might be possible to revive the existing draft.

~ngp

Hi,

> I'm wondering if there's any desire to further the BARE draft RFC
> through the process of getting properly standardized. It's been awhile
> since I've read through the process, so I'm not sure if the existing
> draft can be unarchived, but I'm interested in reviving this and
> trying to push it through. I figured I would check in here first,
> especially as it might be possible to revive the existing draft.

I am going to rewrite some formulations and send again to Independent
Submission Editor (ISE) for publication in Informational track. ISE was
my first contact in IETF and recommended to try publishing BARE in the
Standard track, but from the responses in the ART mailing list and
communication with IETF, I don't think that will happen.

If you want to track the work, see

https://git.sr.ht/~qeef/draft-devault-bare/

As always, I am sorry for being so slow.

On Sat Feb 3, 2024 at 3:51 PM CST, Jiri Vlasak wrote:
> I am going to rewrite some formulations and send again to Independent
> Submission Editor (ISE) for publication in Informational track. ISE was
> my first contact in IETF and recommended to try publishing BARE in the
> Standard track, but from the responses in the ART mailing list and
> communication with IETF, I don't think that will happen.
>
> If you want to track the work, see
>
> https://git.sr.ht/~qeef/draft-devault-bare/
>
> As always, I am sorry for being so slow.


Ok cool, I just wanted to if someone else was working on it.
Let's take this discussion elsewhere then. Would it be reasonable to create a BARE
messages mailing list?

> As always, I am sorry for being so slow.

No worries at all :)

~ngp

On Mon, Feb 05, 2024 at 08:47:56AM -0600, Noah Pederson wrote:
> On Sat Feb 3, 2024 at 3:51 PM CST, Jiri Vlasak wrote:
> > I am going to rewrite some formulations and send again to Independent
> > Submission Editor (ISE) for publication in Informational track. ISE was
> > my first contact in IETF and recommended to try publishing BARE in the
> > Standard track, but from the responses in the ART mailing list and
> > communication with IETF, I don't think that will happen.
> >
> > If you want to track the work, see
> >
> > https://git.sr.ht/~qeef/draft-devault-bare/
> >
> > As always, I am sorry for being so slow.
> 
> 
> Ok cool, I just wanted to if someone else was working on it.
> Let's take this discussion elsewhere then. Would it be reasonable to create a BARE
> messages mailing list?

When I started working on BARE, I asked Drew if I can use his public
mailing list for work. He agreed and I am glad he looks over the BARE
development by just reading emails. The same goes for all the others who
contribute to BARE. I would stick with this mailing list.

> When I started working on BARE, I asked Drew if I can use his public
> mailing list for work. He agreed and I am glad he looks over the BARE
> development by just reading emails. The same goes for all the others who
> contribute to BARE. I would stick with this mailing list.

Sounds good.

I see you updated/republished the draft RFC as well, thank you!

I'm currently working on a schema parser-generator for BARE:

https://git.sr.ht/~chiefnoah/bare-rs

As part of that development, I've come across a few ambiguities.


From RFC section 3.3:

> Union type members are assigned a tag in the order that they appear,
> starting from zero and incrementing by one for each subsequent type.
> If a tag value is explicitly specified, automatic assignment
> continues from that value plus one for subsequent values.

It is not specified how to handle non-incrementing tag assignments. For example:

    type MyUnion = union { uint = 2 | int = 1 | bool };

The 3rd member (`bool`), according to the RFC should have the tag value of `2`. As
written, this a valid schema but will result in a broken message.

There is a similar issue for enum as well.

As written, the following would be valid as well, while obviously being incorrect:

    type MyEnum = enum { A = 1 B = 1 C = 1 };

Further, from section 2.4:

> *  Unions MUST have at least one type, and each type of a union MUST
>    be unique.

Not only the value, but the tag must be unique, otherwise it will be ambiguous what type
a tag represents.

I propose we add another invariant or sentence to the Union invariant along the lines
of:

> *  Unions MUST have at least one type, each type of a union MUST
>    be unique, and each tag MUST only be associated with one type.

A similar modification could be made to the enum invariant section, but I believe the
ambiguity is only really present in the DSL/schema language, as there is no distinction
between the enum uint representation and its identity.

In general, I think the schema language is slightly under-specified, with little in
terms of error or conflict resolution defined. IMO it should either be fleshed out a
little bit more, or added as a separate RFC where it gets fully specified. As it's
referenced fairly heavily as a textual representation in the current RFC, I think adding
a few sections on it would be good.

As an example:

The above schema snippet, specifying a union tag that is not strictly incrementing,
could be considered an error in the schema language.

Thoughts? I'm happy to send over patches.

> I see you updated/republished the draft RFC as well, thank you!

Yes. I also finally asked ISE for publication in independent stream [1].

> I'm currently working on a schema parser-generator for BARE:
> 
> https://git.sr.ht/~chiefnoah/bare-rs

Nice. When ready, please, don't forget to send patch to update
baremessages.org [2], thanks.

> As part of that development, I've come across a few ambiguities.

[...]

> I propose we add another invariant or sentence to the Union invariant along the lines
> of:
> 
> > *  Unions MUST have at least one type, each type of a union MUST
> >    be unique, and each tag MUST only be associated with one type.

That sounds good, I will update that invariant accordingly.

> A similar modification could be made to the enum invariant section, but I believe the
> ambiguity is only really present in the DSL/schema language, as there is no distinction
> between the enum uint representation and its identity.

Agree.

> In general, I think the schema language is slightly under-specified, with little in
> terms of error or conflict resolution defined. IMO it should either be fleshed out a
> little bit more, or added as a separate RFC where it gets fully specified. As it's
> referenced fairly heavily as a textual representation in the current RFC, I think adding
> a few sections on it would be good.
> 
> As an example:
> 
> The above schema snippet, specifying a union tag that is not strictly incrementing,
> could be considered an error in the schema language.
> 
> Thoughts? I'm happy to send over patches.

I agree with improving the draft. I am a bit scared about "adding a few
sections", though. I would like to keep BARE as simple as possible.

Would for example adding "3.4 Invariants" be sufficient?

Thanks!


[1]: https://datatracker.ietf.org/doc/draft-devault-bare/history/
[2]: https://git.sr.ht/~sircmpwn/baremessages.org

On Wed Feb 21, 2024 at 2:15 PM CST, Jiri Vlasak wrote:
> > I see you updated/republished the draft RFC as well, thank you!
>
> Yes. I also finally asked ISE for publication in independent stream [1].

Awesome! Let me know if there is anything I can do with this.

> > I'm currently working on a schema parser-generator for BARE:
> > 
> > https://git.sr.ht/~chiefnoah/bare-rs
>
> Nice. When ready, please, don't forget to send patch to update
> baremessages.org [2], thanks.

Will do

> > A similar modification could be made to the enum invariant section, but I believe the
> > ambiguity is only really present in the DSL/schema language, as there is no distinction
> > between the enum uint representation and its identity.
>
> Agree.
>
> > In general, I think the schema language is slightly under-specified, with little in
> > terms of error or conflict resolution defined. IMO it should either be fleshed out a
> > little bit more, or added as a separate RFC where it gets fully specified. As it's
> > referenced fairly heavily as a textual representation in the current RFC, I think adding
> > a few sections on it would be good.
> > 
> > As an example:
> > 
> > The above schema snippet, specifying a union tag that is not strictly incrementing,
> > could be considered an error in the schema language.
> > 
> > Thoughts? I'm happy to send over patches.
>
> I agree with improving the draft. I am a bit scared about "adding a few
> sections", though. I would like to keep BARE as simple as possible.
>
> Would for example adding "3.4 Invariants" be sufficient?

Yeah, I don't think we need to add a lot. The schema specification is simple enough that
I only noticed a few ambiguities and I'd also like to keep things simple.

I'll see if I can find the time to create a patch.

Also sorry for the slow response, life has been a bit hectic for me.

~ngp

> Yeah, I don't think we need to add a lot. The schema specification is simple enough that
> I only noticed a few ambiguities and I'd also like to keep things simple.
> 
> I'll see if I can find the time to create a patch.

If you don't have time, do not hesitate to just send your (draft) ideas
here. I will process them, include them in the specification and ask for
feedback. This is how I understand my role in working on BARE.

> Also sorry for the slow response, life has been a bit hectic for me.

Please don't be sorry. We can't compare in the slowness of responses.
(Because I would win.)

On Wed Feb 21, 2024 at 2:15 PM CST, Jiri Vlasak wrote:
> I agree with improving the draft. I am a bit scared about "adding a few
> sections", though. I would like to keep BARE as simple as possible.
>
> Would for example adding "3.4 Invariants" be sufficient?

After looking through this again, I think the ambiguity is actually in how to
handle an overlapping union identifier/discriminant or enum value in a schema
parser-generator.

I propose we add a sentence to union and enum paragraphs in
"3.3 Semantic Elements" that explicitly tells parsers how to handle cases where
the discriminant/value would otherwise overlap:


> Enum values are also informational.  Values without an integer token
> are assigned automatically in the order that they appear, starting
> from zero and incrementing by one for each subsequent unassigned
> value.  If a value is explicitly specified, automatic assignment
> continues from that value plus one for subsequent enum values.

If an enum value would overlap with another value for this enum, code generation
tools MUST error and an appropriate error message SHOULD be provided.

> Union type members are assigned a tag in the order that they appear,
> starting from zero and incrementing by one for each subsequent type.
> If a tag value is explicitly specified, automatic assignment
> continues from that value plus one for subsequent values.

If a tag value would overlap with another tag value for this union, code
generation tools MUST error and an appropriate message SHOULD be provided.



Feel free to change the text or grammar. I'd send a patch, but I'm not quite
sure where the source of the RFC lives.

> Feel free to change the text or grammar. I'd send a patch, but I'm not quite
> sure where the source of the RFC lives.

Its here https://git.sr.ht/~qeef/draft-devault-bare/

I will look at your suggestions and incorporate them in the draft. Thank
you.