Skip to content
This repository has been archived by the owner on Oct 7, 2019. It is now read-only.

GeneralizedTime is not C-OER compliant #37

Open
sublimator opened this issue Jul 16, 2018 · 10 comments
Open

GeneralizedTime is not C-OER compliant #37

sublimator opened this issue Jul 16, 2018 · 10 comments

Comments

@sublimator
Copy link
Member

Relevant to:
interledger/rfcs#440

See impl:
https://github.com/interledgerjs/ilp-packet/blob/master/src/utils/date.ts#L43

Considering:

> new Date().toISOString()
'2018-07-16T08:37:52.250Z'

Non significant 0s and decimal points should be stripped from the microseconds at the least ? ( at the least meaning I'm not entirely clear about all the rules, but have noticed some by playing briefly with the encoding features of ASN.1 studio from OSS.com )

@sublimator
Copy link
Member Author

sublimator commented Jul 16, 2018

Some relevant docs:
X.690-201508 (DER/BER/CER)
X.696-201508 (OER/C-OER)

@adrianhopebailie
Copy link
Contributor

I don't think GeneralizedTime is used anywhere anymore. If it is then that is likely a bug.

That function should probably be marked as deprecated and removed soon to avoid confusion.

@sublimator
Copy link
Member Author

Yeah, ILP is a bit hard to follow with all the churn. I understand that it's mostly quietened down but it seems the waters have yet to clear.

Functions using GeneralizedTime:

deserializeIlqpLiquidityResponse
serializeIlqpLiquidityResponse
serializeIlpError
deserializeIlpError

I understand IlpError is from 'legacy' ILP and ILQP is from the quoting protocol. Whatever that means ...

How long will they be deprecated for before being dropped ? Does being deprecated preclude bug fixes ?

@sublimator
Copy link
Member Author

@adrianhopebailie

I see a commit with with the message add asn for ilp4

The InterLedgerPacket definition still contains InterledgerProtocolErrorData which is using GeneralizedTime.

What's a good resource for the short of time for determining the status of these protocols? You mentioned some are deprecated.

@emschwartz
Copy link
Member

ILPv4 only includes IlpPrepare, IlpFulfill, and IlpReject so all of the others should be considered deprecated.

@sublimator
Copy link
Member Author

Thanks Evan.

Is anyone still using ILP != 4?

@emschwartz
Copy link
Member

Not on the live network at least (cause connectors won't forward those packets)

@sublimator
Copy link
Member Author

I'll say from a noob perspective the 'legacy' naming seems to indicate that it's still supported. ILP might be more approachable if the past was swept away somewhere

rfcs/deprecated or something :)

Although, I'm coming at this perhaps from an unusual direction, picking a hyperledger/quilt issue as entry point: hyperledger-archives/quilt#142

@adrianhopebailie
Copy link
Contributor

I'm busy reviewing a lot of the code and docs in the interledger/rfcs and interledgejs/ilp-core etc repos to weed out old stuff. It's very confusing for anyone new.

Actually discussed this with @justmoon yesterday and planning to do a good clean out. Your point is well taken 👍

@sublimator
Copy link
Member Author

sublimator commented Jul 21, 2018 via email

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

No branches or pull requests

3 participants