Phrasing about extensions in RFC 3 can be misleading

[sharafian]

At several points in RFC 3, the spec describes the extension byte at the end of the packet as being "always 0." This could be very misleading to implementors, who might write a parser that expects the extensions byte to be zero. If someone wrote a parser in that way, it would be unable to parse packets where the extensions are actually used. We should instead say that the packet should always be written as 0 for now, but should be entirely ignored while parsing.

[michielbdejong]

The new packet types don't have an extensions field anymore, see https://github.com/interledger/rfcs/blob/master/asn1/InterledgerProtocol.asn vs. https://github.com/interledger/rfcs/blob/master/asn1/LegacyInterledgerProtocol.asn

[emschwartz]

It doesn't have the field but I think @justmoon said that was because he realized you didn't need the extra byte there in order to stick extensions on the end later (if I'm right about that, we need to document exactly what the expectations are around passing on extensions)

[adrianhopebailie]

you didn't need the extra byte there in order to stick extensions on the end later

I don't think that is true. If you are parsing a sequence then there is no leading length indicator to tell you if the sequence is longer than the parts you expect.

If we change the format though we can just introduce new packet type identifiers. The disadvantage being that anyone that encounters them and doesn't support them fails vs extensions which can be parsed but ignored

[sharafian]

If you are parsing a sequence then there is no leading length indicator to tell you if the sequence is longer than the parts you expect.

That's why we have the envelope, though. You may read the whole sequence inside of the envelope, and then have more bytes before the end of the envelope, which you should discard if you don't understand.

[adrianhopebailie]

That's why we have the envelope, though.

There is no envelope around that sequence. The only way to know if the packet is bigger is to depend on the transport protocol you are using to envelope the packets.

[sharafian]

They're all wrapped in https://github.com/interledger/rfcs/blob/master/asn1/InterledgerPacket.asn#L54 , which includes the length prefix and the type ID

[adrianhopebailie]

Based on the discussion around how to encode an Open Type in OER some of this discussion is incorrect.

There IS a length indicator for the packet data after the packet type code. However there is not an ASN.1 extensions indicator in the spec so decoders should NOT expect to find an extension byte.

If a decoder encounters a packet with new fields added then it should ignore those fields and simply pass the remaining bytes in the packet data on to the next node.

@sharafian 's point is still valid that this needs to be documented somewhere.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. \n\n If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.