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

Use const-oid crate? #37

Closed
repnop opened this issue Sep 13, 2021 · 4 comments
Closed

Use const-oid crate? #37

repnop opened this issue Sep 13, 2021 · 4 comments

Comments

@repnop
Copy link
Contributor

repnop commented Sep 13, 2021

Hi, a friend recently made me aware of the const-oid crate which implements const fn new on the type to allow compile-time parsing and construction of the OID from the textual representation, which I think would be quite useful to have re-exported & the Decode and Encode traits implemented for. As far as I can see, the only limitation is that it has a fixed-size internal representation which limits the lengths of the OID values (in bytes), but I'm not sure how much of an issue this would be in practice (it seems most, if not all, of the OIDs that I work with at my job are well below the current limit of 23 bytes for the OID, at least). I would imagine this would likely replace the current ConstOid type in rasn, or at least be available as an opt-in feature. Thoughts?

@XAMPPRocky
Copy link
Collaborator

I would imagine this would likely replace the current ConstOid type in rasn, or at least be available as an opt-in feature. Thoughts?

Thank you for your issue! However I'm not quite sure what the benefits would be for integrating the const-oid crate would be. AFAICT there's only difference between the textual representation and rasn::types::ConstOid is using , as a separator instead of .. That's not enough to me to introduce a crate boundary for such a fundamental type. I would use the parser to provide it as a method if that was exposed but it only provides the type.

Though I haven't made an issue for it, I do also have features and improvements to the API that I'd still like to add to the OID types, and want to keep a good amount of flexibility. For example, I'd like to be write the following in the future, which would allow you to share and re-use oid arcs like you can in the ASN.1 language.

oid! { iso(1), IDENTIFIED_ORGANISATION(3), DOD(6), INTERNET(6) }
oid! { ISO_IDENTIFIED_ORGANISATION_DOD_INTERNET, DIRECTORY(1) }

// Generates

const  ISO_IDENTIFIED_ORGANISATION: Oid = oid![1, 3];
const  ISO_IDENTIFIED_ORGANISATION_DOD: Oid = oid![ISO_IDENTIFIED_ORGANISATION, 6];
const  ISO_IDENTIFIED_ORGANISATION_DOD_INTERNET: Oid = oid![DOD, 1];
const  ISO_IDENTIFIED_ORGANISATION_DOD_INTERNET_DIRECTORY: Oid = oid![ISO_IDENTIFIED_ORGANISATION_DOD_INTERNET, 1];

@repnop
Copy link
Contributor Author

repnop commented Sep 13, 2021

Gotcha, understandable. The current code that I work with at my job uses the string . notation pretty much everywhere which is why const-oid caught my eye (I also think its a bit easier to read as its more compact, and avoids the need for a proc macro for parsing), and figured I'd mention it in case it was useful enough to reduce the number of competing OID types. Thank you for the quick response 😃

@repnop repnop closed this as completed Sep 13, 2021
@XAMPPRocky
Copy link
Collaborator

XAMPPRocky commented Sep 13, 2021

(I also think its a bit easier to read as its more compact, and avoids the need for a proc macro for parsing

Well just to be clear, I used macro syntax above, but what I proposed could be done in const once there's the ability to have const trait, and I am waiting on const to get more featureful to add those kinds of features.

figured I'd mention it in case it was useful enough to reduce the number of competing OID types.

I mean I think it would be fair to ask const-oid maintainers if they'd want to add optional rasn definitions. The conversion would be there just in const-oid rather than rasn. The whole point of rasn's design to allow you to reuse different types across crates. Just like how certain crates have a serde feature to enable serialisation.

@repnop
Copy link
Contributor Author

repnop commented Sep 13, 2021

Yup that seems reasonable to me, if I decide to use it, I'll open an issue on their repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants