docs(asn1): ilp version 4 I guess

[justmoon]

No description provided.

[emschwartz]

Can we put expiresAt before the executionCondition? It's a minor point but that way the two fields that are modified at every hop come first and connectors leave the rest the same

[sappenin]

Can we also add a comment to the expiresAt to indicate that it changes at each hop (like the comment on local amount)?

[justmoon]

executionCondition is a fixed size field, whereas expiresAt is a variable-length field with a length prefix. The idea here was that we felt that it was more important to put all the fixed size fields at the beginning than all the modifiable fields.

In case you're surprised that Timestamp is variable length: The CANONICAL-OER spec says to use the DER spec and the DER spec says that you must leave out trailing zeros in the milliseconds and you must leave out the period if the milliseconds are entirely zero. The rest is always required. It also says you must use UTC time (Z), not local time zones.

So, the spec says:

• 2017-12-24T16:14:32.279Z -> 20171224161432.279Z
• 2017-12-24T16:14:32.200Z -> 20171224161432.2Z
• 2017-12-24T16:14:32.000Z -> 20171224161432Z
• 2017-12-24T16:14:30.000Z -> 20171224161430Z
• 2017-12-24T16:14:00.000Z -> 20171224161400Z
• 2017-12-24T16:10:00.000Z -> 20171224161000Z
• 2017-12-24T16:00:00.000Z -> 20171224160000Z
• 2017-12-24T10:00:00.000Z -> 20171224100000Z
• 2017-12-24T00:00:00.000Z -> 20171224000000Z
• 2017-12-24T18:14:32.000+0200 -> 20171224161432Z

There was a bit of a hubbub at ITU at one point because they had defined GeneralizedTime in terms of ISO 8601 and then later realized that ISO 8601 actually allows infinite precision, not just milliseconds. This was resolved by saying that GeneralizedTime was limited to millisecond precision. (Which is what most implementors had used.)

The DER spec says that you must use the period as the decimal separator. (ISO 8601 allows both period and comma.) The BER spec also says that midnight must be 00:00:00 on the following day. In BER and OER the seconds and minutes are optional, but in DER and C-OER they are required. So these are all invalid:

• 20171224215312.4318Z -> INVALID, too much precision
• 20171224161432,279Z -> INVALID, wrong decimal element
• 20171224240000Z -> INVALID, wrong representation of midnight
• 201712242153Z -> INVALID, missing seconds
• 2017122421Z -> INVALID, missing seconds and minutes

The overall conclusion from reviewing GeneralizedTime: Time is very subtle, but I really like what ISO/ITU ended up with. Fixed-length would have been nice, but it makes sense why they didn't go that way. I need to look at our implementation again to make sure it's correct. I also wrote up a first draft of an OER guide for Interledger.

[sappenin]

I'm probably just not understanding the totality of the new flow, but why is the forwardedBy no longer in this error? Won't the receiver of a reject-message pass it back to any prior nodes in the payment chain?

[emschwartz]

The flow is the same but we thought the forwardedBy field was unnecessary. Connectors can pass the error back without needing to modify it to add their address. The feeling was that this field was a bit annoying to deal with, it has the potential to get very large and be abused, and doesn't provide that much value because you mostly care about knowing who threw the error.

[emschwartz]

(This PR doesn't actually modify IL-RFC 4)

[adrianhopebailie]

Why is the amount back in the ILP packet?

[michielbdejong]

This time it's the transfer amount, not the destination amount

[adrianhopebailie]

I don't follow why this is required at this layer?

[michielbdejong]

Because of #359