Re: [dtn] [EXTERNAL] Re: draft-ietf-dtn-bpbis-25: ABNF "dtn" URI scheme

Weirdly, I don’t remember reading Alvar’s email of May 29 and I don’t have it in my records.  I certainly agree with his suggestion regarding the definition of dtn-hier-part.

The intent of the dtn scheme ABNF in the bpbis specification was simply to document the syntax that has long been common practice, and I have no doubt that this documentation can be improved.  The introduction of a new authority concept was not intended, nor the establishment of a structured hierarchy among DTN operators.  In practice, though, I think the node names used in dtn-scheme EIDs are usually DNS names that conform to these semantics, so perhaps we are already implicitly aligned.  Addressing these semantic points explicitly could be time-consuming and even contentious, so I would prefer that the bpbis specification remain generally silent on them.

But I agree with the suggestion to revise the definition of node-name.

Scott

From: dtn <dtn-bounces@ietf.org> On Behalf Of Loiseau lucien
Sent: Tuesday, September 1, 2020 2:09 AM
To: Alvar Penning <post@0x21.biz>
Cc: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] draft-ietf-dtn-bpbis-25: ABNF "dtn" URI scheme

Hi all,

I am bumping libdtn [1] to upgrade it with latest development (currently version 26)
 and I have the same question as Alvar. Can we have clarification for the dtn uri specification?

Also, thinking about the implications of this update for the dtn scheme, the RFC 3986
states that the double slash should only be used if authority is present.

> URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

>

>       hier-part   = "//" authority path-abempty

>                   / path-absolute

>                   / path-rootless

>                   / path-empty

>

>    [..] When authority is not present, the path cannot begin with two slash

>    characters ("//").

An authority carries a sense of hierarchy as it creates a namespace:

> 3.2.  Authority

>

>    Many URI schemes include a hierarchical element for a naming

>    authority so that governance of the name space defined by the

>    remainder of the URI is delegated to that authority (which may, in

>    turn, delegate it further).
So I wonder about the motivation for this update, because until recently the dtn eid did not carry any semantic,
but now it does carry a sense of authority,  is the goal to create a structured hierarchy among dtn operators ?

Also another question maybe for Ed, with the introduction of DTN authorities, should BPSEC be updated to be
able to carry a certificate that would authenticates a source EID? This could be done with the common-name
field in the X.509 format that encompasses all dtn eid that belongs to a certain namespace. For instance,
a Common Name: myauthority that apply to all the bundle whose source EID starts with dtn://myauthority/

pushing it further, we could have a hierarchy *.myauthority covering all the possible sub-namespace:

dtn://sub1.myauthority/
dtn://sub2.myauthority/

also node-name is specified as at list of at least 1 VCHAR which is the set of all visible character,
The VCHAR set does include the '/' which is used for the name-delim so that we won't be able to
separate the node-name from the demux without making assumptions.
Given this, I suggest to change the specification of node-name to prevent ambiguity with the slash:

node-name = 1* ( ALPHA / DIGIT / "-" / "." / "_"  )

Regards,
Lucien

[1] https://github.com/DisruptedSystems/Terra/<https://urldefense.us/v3/__https:/github.com/DisruptedSystems/Terra/__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAOpRd0RI$>
[2] https://www.ietf.org/rfc/rfc3986.txt<https://urldefense.us/v3/__https:/www.ietf.org/rfc/rfc3986.txt__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAmDogEN0$>

On Fri, May 29, 2020 at 8:58 PM Alvar Penning <post@0x21.biz<mailto:post@0x21.biz>> wrote:
Dear all,

thanks for releasing the 25th draft of the Bundle Protocol. As I read
the changes, I found the Augmented Backus-Naur Form of the URI schemas
quite useful. However, I have a question about this.

In section 4.1.5.1.1[0] a straight forward ABNF is defined for the
"dtn" URI scheme:

> dtn-uri = "dtn:" dtn-hier-part
> dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
> node-name = 1*VCHAR
> name-delim = "/"
> demux = *VCHAR

Some `dtn-uri` is defined as the concatenation[1] of "dtn:" and a
`dtn-hier-part`. A `dtn-hier-part` starts with two leading slashes
("//") and one slash ("/", `name-delim`) follows a nonempty
`node-name`. Various characters might follow. The line ends with a
comment[2].

Thus, some "dtn" URI has at least the following form: "dtn://NODE-NAME/"

The following paragraph within this section defines the null endpoint as
"dtn:none". However, as far as I understand this does not fit the ABNF
defined above.

If I am not wrong on this, I would like to suggest a new rule for the
"none" `dtn-hier-part`. This could look like the following:

> dtn-hier-part =  "none"
> dtn-hier-part =/ "//" node-name name-delim demux

Otherwise, the null endpoint could be renamed to "dtn://none/" to match
the current ABNF. Note, a node named "none" and the null endpoint may
get mixed up.

I would be pleased about comments in this regard.

Best regards,
Alvar

[0]:https://tools.ietf.org/html/draft-ietf-dtn-bpbis-25#section-4.1.5.1.1<https://urldefense.us/v3/__https:/tools.ietf.org/html/draft-ietf-dtn-bpbis-25*section-4.1.5.1.1__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAcIILQZc$>
[1]:https://tools.ietf.org/html/rfc5234#section-3.1<https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5234*section-3.1__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAZdR4jr4$>
[2]:https://tools.ietf.org/html/rfc5234#section-3.9<https://urldefense.us/v3/__https:/tools.ietf.org/html/rfc5234*section-3.9__;Iw!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAgtylS2U$>

_______________________________________________
dtn mailing list
dtn@ietf.org<mailto:dtn@ietf.org>
https://www.ietf.org/mailman/listinfo/dtn<https://urldefense.us/v3/__https:/www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!esNuxLhIPWgsslEXSHFsrjNvlfDe9F3oxwrgXcLK6dloeJlVpAvfiuNXDpGQWo46uAMAMgrCwKY$>

--
--
Lucien Loiseau