[jira] [Comment Edited] (DAFFODIL-1781) stream encoders/decoders - e.g., ASN.1 Object Identifier

["Michael Beckerle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DAFFODIL-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382262#comment-16382262 ] 

Michael Beckerle edited comment on DAFFODIL-1781 at 3/1/18 4:33 PM:
--------------------------------------------------------------------

There is a general ticket about the underlying mechanism needed for this, base64, folded lines, etc. which is DAFFODIL-1734.

So I edited this ticket to be about the specific ASN.1 object identifier encoding. We have been asked if we could support ASN.1 data that uses these object IDs, but no actual use case has been identified.

Priority lowered and moved to "deferred" release target.



was (Author: mbeckerle):
There is a general ticket about the underlying mechanism needed for this, base64, folded lines, etc. which is DAFFODIL-1734.

So I edited this ticket to be about the specific ASN.1 object identifier encoding. We have been asked if we could support ASN.1 data that uses these object IDs, but no actual use case has been identified.



> stream encoders/decoders - e.g., ASN.1 Object Identifier
> --------------------------------------------------------
>
>                 Key: DAFFODIL-1781
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1781
>             Project: Daffodil
>          Issue Type: New Feature
>          Components: Back End, DFDL Language, Front End
>            Reporter: Michael Beckerle
>            Priority: Minor
>             Fix For: deferred
>
>
> Some data types are encoded in ways we can't decode.
> Good example of this is an ASN.1 DER "Object Identifier".
> Another good example of this is a Google Protocol Buffers zig-zag integer.
> Another example of this is the payload of a mil-std-2045 header - the payload can be specified as "compressed", and must be decompressed when parsing, recompressed when unparsing.
> ��
> This ticket may be mixing some issues.
>  * Primitive representations of string, int, etc.
>  * decoding of a representation before subsequently parsing it, or the inverse for unparsing
> In general DFDL/Daffodil needs extensibility of this kind, so that every time someone runs into a format with some encoding not anticipated by the DFDL standard we don't have to add it into the Daffodil implementation as a special case.
> We need the ability to extend by adding a jar of specifically-setup libraries, and augmenting a schema with declarations that the extension be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)