Support for constraints

[naveedpash]

Hey, amazing crate!

Any update on when this crate will support constraints?

I'm implementing the IEEE 11073 standard for medical device communication in Rust. It encodes its data types in ASN.1 BER and DER. My implementation targets embedded environments so it would really save me memory and storage if I can constraint data types to u8/16/32 as per the IEEE 11073 recommendations.

[XAMPPRocky]

Thank you for your issue! I’m still working on supporting constraints as part of the framework, but I don’t have any plans for when though as I work on this in my spare time and mostly focused on other things at the moment. However you can already use fixed sized integer types like u8, u16, u32, u64.

[naveedpash]

:O Really?

So if I write the following:

#[derive(AsnType)]
struct Person {
    #[rasn(tag(0))]
    age: u8,
    name: String,
}

then any instance of Person.age will always have u8 size in the resulting encoded ASN? (sorry if I'm being nit-picky, I just want to be sure that's how I should declare it)

[XAMPPRocky]

(sorry if I'm being nit-picky, I just want to be sure that's how I should declare it)

No worries, feel free to ask me any questions.

then any instance of Person.age will always have u8 size in the resulting encoded ASN?

In ASN.1 BER and DER there's no concept of constrained types in the actual encoding itself, there's only INTEGER. So yes that will work just fine for encoding, and then when decoding rasn will try to convert it from a INTEGER into a u8 and provide an error if it's outside the range.

[naveedpash]

Awesome (and very prompt reply I must say) I'll close this issue then because this indirectly gives me the "constraints" I need.

[XAMPPRocky]

I'm going to keep this open, since there's a need to support constrained types in general for encodings like PER.

[ouyangbob]

I'm going to keep this open, since there's a need to support constrained types in general for encodings like PER.

When will PER, UPER, OER and COER be supported？

[XAMPPRocky]

When will PER, UPER, OER and COER be supported？

Indeterminate, this a project I work on in my spare-time on-top of my other projects and a full-time job. It is the feature I want to work on next however.

[ouyangbob]

When will PER, UPER, OER and COER be supported？

Indeterminate, this a project I work on in my spare-time on-top of my other projects and a full-time job. It is the feature I want to work on next however.

thanks

[naveedpash]

I know you're busy, just have a question that is not urgent. I'm asking this question in reference to my discussion #40

Would would the syntax look like for named constraints on different asn.1 types?

Take for example the following asn.1 schemas:

Number 1:

User-session-requirements ::= BIT STRING {
  half-duplex (0),
  duplex (1),
  expedited-data (2),
-- and so forth
}

Number 2:

Result ::= INTEGER {
  acceptance (0),
  user-rejection (1),
  provider-rejection (2)
}

It seems international organisations represent enums using various asn.1 types according to how much space they feel that value should occupy in the PDU.

For these kind of cases I would like the suggest the following:

#[derive(Debug, AsnType, Encode, Decode)]
#[rasn(repr(BITSTRING))]
enum UserSesionRequirements {
  #[rasn(value(0))]
  HalfDuplex,
  #[rasn(value(1))]
  Duplex,
  #[rasn(value(2))]
  ExpeditedData,
  // and so forth 
}

This way, the code would be expressive and sit well with the language server while rasn takes care of the details under the hood. Does that sound right?

[Nicceboy]

Seems like some constraints were added as part of APER/UPER encoding. Is it possible to include some sort of documentation? I have been reading the code and I am not entirely sure yet about the whole logic.

Seems like you can use them with macros as well?

quote! {
    #crate_root::types::Constraints::new(&[
        #size
        #value
        #extensible
        #from
    ])
}

I don't understand the difference of these yet. You can set range for both value and from. What is closest to the ASN.1 range, e.g. adding rasn data structure for Uint3 ::= INTEGER (0..7)?

For example test case to use them https://github.com/XAMPPRocky/rasn/blob/34a868615075eda763478281626c18bc16806214/tests/personnel.rs#L329

[XAMPPRocky]

Is it possible to include some sort of documentation? I have been reading the code and I am not entirely sure yet about the whole logic.

Yeah I sorry, I added them but didn't focus on documentation. The Personnel test, the PKIX crate, and the CAP crate, are the best reference material right now. It's mostly designed to look like ASN.1 constraints.

What is closest to the ASN.1 range, e.g. adding rasn data structure for Uint3 ::= INTEGER (0..7)?

#[derive(AsnType, Decode, Encode, Debug, PartialEq)]
#[rasn(delegate, value("0..=7"))]
pub struct UInt3(pub Integer);

[Nicceboy]

I wonder if this issue is relevant anymore and can be closed? There is pretty good support now. BER does not use it yet, but there is another issue for that. Also documentation is on PR: https://github.com/XAMPPRocky/rasn/pull/159

[XAMPPRocky]

Yes this can be closed