Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message format defined by prior negotiation #609

Closed
10 tasks done
treiher opened this issue Mar 18, 2021 · 1 comment · Fixed by #765
Closed
10 tasks done

Message format defined by prior negotiation #609

treiher opened this issue Mar 18, 2021 · 1 comment · Fixed by #765
Assignees
Labels
architectural decision Discussion of design decision

Comments

@treiher
Copy link
Collaborator

treiher commented Mar 18, 2021

Context and Problem Statement

There are multiple existing communication protocols where the message format is defined by prior negotiation. The field length (Componolit/systematization-binary-schemas#28) as well as the field type (Componolit/systematization-binary-schemas#53) can be affected.

Considered Options

O1 Generic message type with types as formal parameters (#133)

+ Also usable for different purposes (cf. #133)
Not directly applicable for variable-length opaque field in DTLS 1.3, NTP, QUIC
Probably only instances of generic type could be verified

O2 Variant message type with scalars as discriminants

The discriminant could be used in conditions (SPDM, TLS 1.3) and in length aspects (DTLS 1.3, NTP, QUIC).

+ Applicable in all known instances
+ Extension of message verification is simple: references to discriminants can be handled similar as references to fields

Decision Outcome

O2 is the only viable option.

Tasks

  • Decide naming: variant messages, discriminated messages or parameterized messages.
    • Decision: Parameterized Messages
  • How could a condition on the discriminants/parameters be defined (restricting allowed parameter values or parameter combinations before evaluation of first message field)?
  • Decide: Allow the definition of the first field by a parameter value?
  • Extend specification parser
  • Extend message model
  • Extend code generator for messages
  • Extend session model
  • Extend code generator for sessions
  • Support use of parameterized messages as field types
  • Amend documentation

The support for parameterized messages in PyRFLX will be added in a subsequent issue (#743).

@treiher treiher added this to To do in RecordFlux Future via automation Mar 18, 2021
@treiher treiher added v0.5.0 architectural decision Discussion of design decision labels Jul 9, 2021
@treiher treiher removed this from To do in RecordFlux Future Jul 26, 2021
@treiher treiher added this to To do in RecordFlux 0.6 via automation Jul 26, 2021
@treiher treiher self-assigned this Aug 4, 2021
@treiher treiher moved this from To do to In progress in RecordFlux 0.6 Aug 4, 2021
@treiher
Copy link
Collaborator Author

treiher commented Aug 17, 2021

package Test is

   type Length is range 1 .. 2**14 - 1 with Size => 16;

   type Message (Length : Length; Extended : Boolean) is··
      message
         Data : Opaque
            with Size => Length * 8
            then Extension
                if Extended = True
            then null
                if Extended = False;
         Extension : Opaque
            with Size => Length * 8;
      end message;

   generic
      C : Channel with Readable, Writable;
   session Session with
      Initial => Receive,
      Final => Terminated
   is
      M_R : Message;
   begin
      state Receive
      is
      begin
         M_R'Reset (Length => 2, Extended => False);
         C'Read (M_R);
      transition
         then Reply
            if M_R'Valid
         then Terminated
      end Receive;

      state Reply
      is
      begin
         C'Write (Message'(Length => M_R.Length, Extended => True, Data => M_R.Data, Extension => [3, 4]));
      transition
         then Terminated
      exception
         then Error
      end Reply;

      state Error
      is
      begin
         transition
            then Terminated
      end Error;

      state Terminated is null state;
   end Session;

end Test;

@treiher treiher moved this from In progress to Under review in RecordFlux 0.6 Sep 6, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 7, 2021
treiher added a commit that referenced this issue Sep 13, 2021
RecordFlux 0.6 automation moved this from Under review to Merged Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
treiher added a commit that referenced this issue Sep 13, 2021
@treiher treiher mentioned this issue Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architectural decision Discussion of design decision
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

1 participant