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

[[e-mail]]

Ed,

As far as I'm concerned, 'www.eds_discount_emporium.com" could be interpreted as a DTN EID. It's up to the ultimate (ransmitting CLA to determine how to interpret that address for the final bundle delivery, and that's where the http+dtn concept comes into effect; there may be a 1:1 relationship between HTTP URLs and DTN EID's.


So, I don't think we need to develop it.


Thanks,

Jeremy

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


I don’t disagree that there are cases where certain schemes do and do not make sense.  For example, using an IP address on a deep-space spacecraft seems unnecessary and using an IPN address on a node on the Internet seems unnecessary.



Maybe a simpler question is: could I have a bundle whose source EID is simply:  “www.eds_discount_emporium.com:1234’  and do we really need to develop a new scheme to represent that?



I certainly defer to those with more knowledge on URI syntax as to whether BPbis should add a defined scheme id to its registry of allowed schemes.



-Ed



Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>



From: [e-mail] <[e-mail]>
Sent: Monday, July 13, 2020 2:53 PM
To: [e-mail]; Birrane, Edward J. <[e-mail]>; [e-mail]
Subject: [EXT] Re: DTN addressing, routing, and ownership



APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking links or attachments




Rick,

I considered both ways, but I think that, for the sake of argument here, the http URI is the "primary" URI, with the IPN portion appended to it. However, you're right, in that you should use the query component(s) as a delimiter. If you use the URI query component as the BP EID, you can maintain full compatibility with L4 load balancers, etc, which can perform forwarding decisions based upon that query. That also maintains compatibility with websocket URI's.



Thanks,

Jeremy

________________________________

From: Rick Taylor <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 13, 2020 6:32:06 PM
To: Mayer, Jeremy; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: DTN addressing, routing, and ownership



Hi Ed,



I’m with Jeremy on this.  HTTP makes a fine CLA as HTTP defines a transport already.   The http:// schema specifies the address *and* the transport.



@Jeremy: would your example be better as http+ipn:[ipn_parts]#[http_resource?query] ?



(One day I will finish my HTTP-REST CLA draft)



Rick



From: dtn [mailto:[e-mail]] On Behalf Of Jeremy.Mayer@dlr..de<mailto:[e-mail]>
Sent: 13 July 2020 15:48
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] DTN addressing, routing, and ownership



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]<mailto:[e-mail]>> on behalf of Birrane, Edward J. <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 13, 2020 3:57:29 PM
To: [e-mail]<mailto:[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?