Re: [dtn] DTN addressing, routing, and ownership

[[e-mail]]

Ed,

Throwing in my $0.02: I'm not entirely sure that http is a valid scheme from this perspective. I consider http (& webSockets, IMAP, carrier pigeon, etc) to be a "CLA++", where it's actually a last-hop convergence layer scheme.

Therefore, it might be preemptive to start creating "non-DTN-specific" scheme names. Instead, we should strongly consider the use of the oft-forgotten-yet-completely-valid '+' character within the scheme name for these types of use-cases. We can use that character to specify dtn/ipn (which essentially outline the behavior of BP) and the the associated CLA path. If we go this way, some schemes would look like: http+ipn://[http URL]#[ipn URI].


Thanks,

Jeremy

________________________________
From: dtn <[e-mail]> on behalf of Birrane, Edward J. <[e-mail]>
Sent: Monday, July 13, 2020 3:57:29 PM
To: [e-mail]
Subject: Re: [dtn] DTN addressing, routing, and ownership

One other comment on supported EID schemes:

The split between DEST and DST_PORT does indeed formally exist for the ipn EID scheme: node number and service number.  We could do the same sort of thing for the dtn scheme, but the WG has not yet reached consensus on the detailed syntax of dtn-scheme EIDs.  It’s not that we haven’t recognized this issue, it’s that the issue is addressed in the EID schemes rather than in the protocol specification itself.

[EJB]  Looking at section 10.6 I see dtn: and ipn: as defined scheme names. Is there something that breaks if we also allow an http: scheme in this registry? For those simpler cases where late binding is *not* needed then a standard IP is fine, and otherwise a “host name” or loopback can be used for late binding instead.

[EJB] In no way am I suggesting to  not use dtn: or ipn:, but perhaps http: should also be included as a possibility?