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

[Loiseau lucien <[e-mail]>]

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/
[2] https://www.ietf.org/rfc/rfc3986.txt

On Fri, May 29, 2020 at 8:58 PM Alvar Penning <[e-mail]> 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
> [1]:https://tools.ietf.org/html/rfc5234#section-3.1
> [2]:https://tools.ietf.org/html/rfc5234#section-3.9
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>


-- 
--
Lucien Loiseau