interledger / rfcs

Specifications for Interledger and related protocols

Home Page:https://interledger.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

InterledgerAddress: Clarify if AllocationScheme is a valid ILP Address

sappenin opened this issue · comments

Bullet-point 4 of Address Requirements in RFC-15 says, "Addresses...MUST contain at least one segment after the allocation scheme prefix."

While this doesn't seem incorrect, it does present problems when trying to model an InterledgerAddress. For example, in Java, an InterledgerAddress object has a method called getPrefix, which returns an optionally-present InterledgerAddress. However, when calling this method on an address like, g.foo, the result must be empty because g is not currently a valid address.

This also causes complexity in routing tables, because we may want to route to an AllocationScheme, but in Java this is not a valid address, per se.

So, my question is: Is there a good rationale to consider an AllocationSchemes as a valid Interledger address?

If the answer is "no", then we technically end up with 3 distinct objects to model ILP addressing:

  1. InterledgerAddress: g.foo, g.foo.bar, but NOT g.
  2. AllocationScheme: g, test1, etc, but NOT g.foo.
  3. InterledgerAddressPrefix: g, test, g.foo, etc.

@sappenin and I discussed this on the last Quilt community call.

Here's the summary (@sappenin , correct me if I'm wrong):

There are two distinct things that need to be modelled, an Interledger Address and an Interledger Address-space. i.e. An address points to an entity on the network whereas an address-space encompasses multiple addresses on the network.

This is somewhat analogous to the a subnet and a host identifier in IP addresses. IP addresses are generally broken up into the network prefix and host identifier with either a subnet mask or CIDR prefix indicating how the address is divided.

As a result it's easy to distinguish between an address (192.168.1.1) and an address-space (192.168.1.0/24) as an address space is expressed in a different form.

It's not so easy with ILP as an address could also be an address-space in a different context. For example, the address g.adrian could be my ILP address but it is also the prefix for all addresses in that address space.

The only exception to this is the allocation-scheme prefix. On it's own this is not a legal address so it MUST be an address-space.

When modelling these two concepts it will be useful to have a flag on the object representation that indicates if the address is intended to be used as address or an address-space to prevent errors. Also, the validation rules will by slightly different as an address-space may have a single segment whereas an address MUST have multiple.