Subject: Re: [Uri-review] Requesting review for 'dvx' provisional registration draft

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Jul 2021 13:24:17 +0100

Hi Clemens,

Thanks for your note.  There appears to be no collision with an existing
registered scheme, so that's good news.  In going through the syntax, I did
have some questions, if you don't mind.

My reading is that there are two current commands, open and close, but that
you intend for the syntax to be extensible.  The permitted characters for
new commands are a-z0-9.+-, and there is no restriction on their ordering.
That would mean 99open, +-7a, even + as a bare operator would be valid; is
that your intent, or did you also want to have minimum lengths and require
certain patterns?

For "the interoperability considerations", you might simply mention that
there is currently only one known context of use (the ORGAPLAN context,
listed below), and that uses of this outside that context may or may not
conform.

For security considerations, I could not quite parse what you meant:

For security reasons it's prohibited to include sensitive or private
information in the uri. This applies in particular to the key=value pairs.
The restrictions on a requested resource or command need to be checked by
the application which evaluates the uri

For example, are you indicating that the URI might be carried in a plain
text protocol, and thus be observable to an attacker with access to the
path?  If that's the threat model, it would appear  the application that
evaluates the URI (on receipt), might be acting too late to prevent
observation.   In general you might want to reference rFC 3552 for text on
how security considerations text is constructed.

Thanks again for sending this note,

regards,

Ted Hardie

Your document says "The encoding of the key=value pairs follow the rules
defined in RFC3986 "Uniform Resource Identifier (URI): Generic Syntax"
Section 2 <https://datatracker.ietf.org/doc/html/rfc3986#section-2>" .
It's not entirely clear to me which part of that section you wish to draw
the reader's attention to.  Is it possible you meant section 3.4, which
describes path elements and mentions key value pairs?

On Thu, Jul 1, 2021 at 5:54 AM C. Bastian | ORGAPLAN <
[email-masked]> wrote:

> Hello! I hope you can provide me some feedback on this draft for a
> provisional registration of the scheme 'dvx'.
> Here's my current draft, any feedback and hints are appreciated. Best
> greetings Clemens
>
> Scheme name:
>       dvx
>
> Status:
>      Provisional
>
> Applications/protocols that use this scheme name:
>      The ERP software solution named "DVX" by ORGAPLAN business
> solutions (www.orgaplan.org)
>
> Contact:
>      Registration applicant: Clemens Bastian <[email-masked]
> >
>      Scheme creator: ORGAPLAN business solutions GmbH <[email-masked]>
>
> Change controller:
>      Someone who is verified to represent ORGAPLAN business solutions
> GmbH (see 'Contact')
>
> References:
>      Specification:
> https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html
>
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: "C. Bastian | ORGAPLAN" <[email-masked]>
Date: Thu, 1 Jul 2021 18:44:20 +0200

Hello Ted,

first of all: Let me thank you for the precious feedback and all the
effort going through my draft.

You're absolutely right in terms of the extensible <command> section.
To be honest, and as the title indicates, this is a draft and changes
can still be made. The scheme design is WiP and your feedback is
appreciated. Now there are some more obligations and recommendations
regarding the <command>:
    * MUST start with a letter (a-z)
    * MUST end with a letter (a-z) or a number (0-9)
    * MUST have a minimum length of 3 characters and a maximum length
of 200 characters
    * SHOULD HAVE at least 3 alphanumeric characters between two
special characters (`.`,`+`,`-`)

The section about encoding of the key=value pairs has been updated as
well to make it clearer (hopefully):
    All `key=value` pairs MUST use the UTF-8
([RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)) character
set. `key` and `value` MUST be separated by an equal sign (`=`).

    Naming of `key` has following obligations:
    * MUST start with a letter (a-z)
    * MUST have a minimum length of 1 character and a maximum length
of 200 characters
    * MUST consist of alphanumeric characters (a-zA-Z0-9) (lowercase
alphabet a-z, uppercase alphabet A-Z, numbers 0-9)
    * SHOULD be written in _camelCase_ annotation

    Data within `value` has following obligations:
    The characters allowed in a `value` are either reserved or
unreserved (or a percent character as part of a percent-encoding
    [RFC3986 "Uniform Resource Identifier (URI): Generic Syntax"
Section 2.1](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)).
    Reserved characters are those characters that sometimes have
special meaning, while unreserved characters have no such meaning.
    Using percent-encoding, characters which otherwise would not be
allowed are represented using allowed characters.

    The unreserved characters can be encoded, but SHOULD NOT be
encoded. The reserved characters MUST be encoded using
percent-encoding.
    List of reserved characters: `!*'();:@&=+$,/?%#[] ` (last
character is a whitespace).

We also updated the interoperability considerations as follows (thanks
for the hint):
    Currently the only one known context of use is within the software
application stack and it's ecosystem provided by ORGAPLAN business
solutions. Uses outside of context should be handled with care.

Last but not least we updated the security considerations. Since this
is a provisional registration and the uri is still WiP we do not have
a well qualified security consideration yet. Is this required for a
provisional registration?

Thanks again for your time Ted, the updated specification is available
at https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html

Looking forward hearing your thoughts and possible improvements!

Am Do., 1. Juli 2021 um 14:24 Uhr schrieb Ted Hardie <[email-masked]>:
>
> Hi Clemens,
>
> Thanks for your note.  There appears to be no collision with an existing registered scheme, so that's good news.  In going through the syntax, I did have some questions, if you don't mind.
>
> My reading is that there are two current commands, open and close, but that you intend for the syntax to be extensible.  The permitted characters for new commands are a-z0-9.+-, and there is no restriction on their ordering.  That would mean 99open, +-7a, even + as a bare operator would be valid; is that your intent, or did you also want to have minimum lengths and require certain patterns?
>
> For "the interoperability considerations", you might simply mention that there is currently only one known context of use (the ORGAPLAN context, listed below), and that uses of this outside that context may or may not conform.
>
> For security reasons it's prohibited to include sensitive or private information in the uri. This applies in particular to the key=value pairs. The restrictions on a requested resource or command need to be checked by the application which evaluates the uri
>
> For example, are you indicating that the URI might be carried in a plain text protocol, and thus be observable to an attacker with access to the path?  If that's the threat model, it would appear  the application that evaluates the URI (on receipt), might be acting too late to prevent observation.   In general you might want to reference rFC 3552 for text on how security considerations text is constructed.
>
> Your document says "The encoding of the key=value pairs follow the rules defined in RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" Section 2" .  It's not entirely clear to me which part of that section you wish to draw the reader's attention to.  Is it possible you meant section 3.4, which describes path elements and mentions key value pairs?
>
>
>
>
> On Thu, Jul 1, 2021 at 5:54 AM C. Bastian | ORGAPLAN <[email-masked]> wrote:
>>
>>      Registration applicant: Clemens Bastian <[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Jul 2021 10:29:49 +0100

Hi Bastian,

Thanks for your message.  I've read the updated document, and I have a few
comments, but I believe I understand more fully your intent than with the
initial version.  Thanks for the update.

In the text on data within values, you say:

The characters allowed in a value are either reserved or unreserved (or a
percent character as part of a percent-encoding, see RFC3986 "Uniform
Resource Identifier (URI): Generic Syntax" Section 2.1
<https://datatracker.ietf.org/doc/html/rfc3986#section-2.1>). Reserved
characters are those characters that sometimes have special meaning, while
unreserved characters have no such meaning. Using percent-encoding,
characters which otherwise would not be allowed are represented using
allowed characters

If I understand you correctly, your intent could also be expressed by
saying that "value" permits the unreserved and pct-encoded  productions
from RFC 3986 (see the Appendix for the collected ABNF).  If you also
wanted to permit the sub-delims, ":" , and "@", you could simply reuse the
pchar production, which seems fairly close to your intent.  Since those are
part of the base spec, either approach would be well understood by
implementers.

On the question of security considerations, BCP35 requires either a
security consideration section or a statement of why one cannot be made
available:

      The scheme definition SHOULD include clear security considerations
      (Section 3.7
<https://www.rfc-editor.org/rfc/rfc7595.html#section-3.7>) or explain
why a full security analysis is not
      available (e.g., in a third-party scheme registration).

I'd suggest updating the template to note that the system of which this is
a part is a work in progress and that a full security consideration is thus
not yet available, but that the scheme inherits the general security
considerations of RFC 3986 and that sensitive data SHOULD NOT be used in
key value pairs in forms accessible to observers.  That would seem to cover
the threats you're already aware of, and you can update the security
considerations as the threat model becomes clearer.

best regards,

Ted Hardie

On Thu, Jul 1, 2021 at 5:44 PM C. Bastian | ORGAPLAN <
[email-masked]> wrote:

> > My reading is that there are two current commands, open and close, but
> that you intend for the syntax to be extensible.  The permitted characters
> for new commands are a-z0-9.+-, and there is no restriction on their
> ordering.  That would mean 99open, +-7a, even + as a bare operator would be
> valid; is that your intent, or did you also want to have minimum lengths
> and require certain patterns?
> >
> Section 2" .  It's not entirely clear to me which part of that section you
> wish to draw the reader's attention to.  Is it possible you meant section
> 3.4, which describes path elements and mentions key value pairs?
> >
> >
> >
> >

---

From: "C. Bastian | ORGAPLAN" <[email-masked]>
Date: Fri, 2 Jul 2021 18:54:09 +0200

Hello Ted,

thanks again. Your thoughts are very appreciated and helpful.
Here's our third version of the draft:

Regarding the obligations for "key=value" pairs your idea helped us to
shrink our specification and make more use of existing documentation.
It now says:
    * value MUST consist of unreserved and pct-encoded characters
defined in RFC3986 (see the RFC3986 Appendix A. for the collected
ABNF)
    * The unreserved characters MAY be pct-encoded, but SHOULD NOT be encoded
    * The reserved characters MUST be encoded using pct-encoding
    * value MAY be empty, but it's not recommended

And the updated security considerations:
    A full security analysis and considerations are not yet available
since the application which this scheme is part of is still under
development. At the current state the scheme inherits the general
security considerations of RFC 3986 Section 7.. We highly recommend:
    Sensitive data SHOULD NOT be used in key=value pairs in forms
accessible to observers
    Implementations of this scheme SHOULD NOT trust a dvx-URI from an
untrusted source
    Security considerations will be updated as soon as the threat
model becomes clearer.

Published as the versions before at
https://api.orgaplan.org/articles/uri-dvx-scheme-specification.html

Looking forward on your feedback, Clemens

Mit freundlichen Gruessen | Best regards

Clemens Bastian | Technical Development & Integrations

ORGAPLAN business solutions GmbH

[email-masked]
T (Global) +49 | 511 | 999 71 0 73

Office UK: HG4 Ripon (Harrogate, Northern Yorkshire)

Office DE: 30926 Seelze / Velber (Hannover)

Office DE: 06618 Naumburg (Saale)

Firmensitz (nur: Verwaltung)

bisher: Hanomaghof 2 | 30449 Hannover

seit 15. Juni 2021: Gustav-Bratke-Str. 71 | DE - 30629 Hannover

www.orgaplan.org

ORGAPLAN business solutions entwickelt funktionsstarke Software für
die kaufmännische und betriebliche Organisation und Information.

Seit über 30 Jahren vertrauen namhafte Unternehmen im technischen
Großhandel, der Fertigungs- und Lebensmittelindustrie sowie dem
Sondermaschinenbau unseren Softwarelösungen.

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss...

Am Fr., 2. Juli 2021 um 11:30 Uhr schrieb Ted Hardie <[email-masked]>:
>
> Hi Bastian,
>
> Thanks for your message.  I've read the updated document, and I have a few comments, but I believe I understand more fully your intent than with the initial version.  Thanks for the update.
>
> The characters allowed in a value are either reserved or unreserved (or a percent character as part of a percent-encoding, see RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" Section 2.1). Reserved characters are those characters that sometimes have special meaning, while unreserved characters have no such meaning. Using percent-encoding, characters which otherwise would not be allowed are represented using allowed characters
>
> If I understand you correctly, your intent could also be expressed by saying that "value" permits the unreserved and pct-encoded  productions from RFC 3986 (see the Appendix for the collected ABNF).  If you also wanted to permit the sub-delims, ":" , and "@", you could simply reuse the pchar production, which seems fairly close to your intent.  Since those are part of the base spec, either approach would be well understood by implementers.
>
> On the question of security considerations, BCP35 requires either a security consideration section or a statement of why one cannot be made available:
>
>       (Section 3.7) or explain why a full security analysis is not
> I'd suggest updating the template to note that the system of which this is a part is a work in progress and that a full security consideration is thus not yet available, but that the scheme inherits the general security considerations of RFC 3986 and that sensitive data SHOULD NOT be used in key value pairs in forms accessible to observers.  That would seem to cover the threats you're already aware of, and you can update the security considerations as the threat model becomes clearer.
>
> best regards,
>
> Ted Hardie
>
> On Thu, Jul 1, 2021 at 5:44 PM C. Bastian | ORGAPLAN <[email-masked]> wrote:
>>
>> Hello Ted,
>>

---

From: Tim Bray <[email-masked]>
Date: Fri, 2 Jul 2021 10:40:29 -0700

Hi, thanks for the drafts. A few comments:

Normally when you register a URI scheme, since the I in URI stands for
"Identifier", you say what resource is being identified and (if applicable)
how it is represented, i.e.  what bytes you get back if you do a GET and
what you should send with a POST or PUT.

I think that this flavor of URI is simply an encoding of a DVX command.  I
get the feeling that what's being addressed here is "The DVX software on
the local machine"?  Is that correct?  If it's correct, did you consider
adding an IP address or domain name? E.g.

dvx:my-dvx-box.example.com:open?key1=val1&key2=val2 or
dvx:192.168.0.33:open?key1=val1&key2=val2

Then for the local machine you'd just say dvx::open?key=val, etc

But if just representing a command on the local machine meets your needs,
OK I guess.  It seems a little weird in a protocol element designed for the
Internet.  And a URI whose effect depends in an unpredictable way on the
state of the local machine also is odd.  What happens if my software
encounters a dvx: URI but there's no DVX software installed?  Maybe you
should say?

In any case, I believe there's no intent to use this to exchange resource
representations?  If true, I think you should probably say that explicitly.

On Fri, Jul 2, 2021 at 9:54 AM C. Bastian | ORGAPLAN <
[email-masked]> wrote:

> > Thanks for your message.  I've read the updated document, and I have a
> few comments, but I believe I understand more fully your intent than with
> the initial version.  Thanks for the update.
> >
> > The characters allowed in a value are either reserved or unreserved (or
> a percent character as part of a percent-encoding, see RFC3986 "Uniform
> Resource Identifier (URI): Generic Syntax" Section 2.1). Reserved
> > I'd suggest updating the template to note that the system of which this
> is a part is a work in progress and that a full security consideration is
> thus not yet available, but that the scheme inherits the general security
> >> > Thanks for your note.  There appears to be no collision with an
> existing registered scheme, so that's good news.  In going through the
> syntax, I did have some questions, if you don't mind.
> >> >
> >> > My reading is that there are two current commands, open and close,
> but that you intend for the syntax to be extensible.  The permitted
> characters for new commands are a-z0-9.+-, and there is no restriction on
> their ordering.  That would mean 99open, +-7a, even + as a bare operator
> would be valid; is that your intent, or did you also want to have minimum
> lengths and require certain patterns?
> >> >
> >> > For "the interoperability considerations", you might simply mention
> that there is currently only one known context of use (the ORGAPLAN
> context, listed below), and that uses of this outside that context may or
> may not conform.
> >> >
> >> > For example, are you indicating that the URI might be carried in a
> plain text protocol, and thus be observable to an attacker with access to
> the path?  If that's the threat model, it would appear  the application
> that evaluates the URI (on receipt), might be acting too late to prevent
> >> > Your document says "The encoding of the key=value pairs follow the
> rules defined in RFC3986 "Uniform Resource Identifier (URI): Generic
> Syntax" Section 2" .  It's not entirely clear to me which part of that
> section you wish to draw the reader's attention to.  Is it possible you
> meant section 3.4, which describes path elements and mentions key value
> pairs?
> >> >
> >> >
> >> >
> >> >

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jul 2021 09:27:18 +0100

Hi Tim,

Remember that this is an application for a provisional, and that some
aspects of the system Clemens is describing are still under development.
Our primary purpose at this stage is to make sure that there are no
collisions and that the syntax fits within the general URI syntax.  If we
can help beyond that, it is of course good.

regards,

Ted

On Fri, Jul 2, 2021 at 6:40 PM Tim Bray <[email-masked]> wrote:

>> Am Fr., 2. Juli 2021 um 11:30 Uhr schrieb Ted Hardie <[email-masked]
>> >:
>> >
>> > Hi Bastian,
>> >
>> >> Section 2.1](
>> https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)).

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jul 2021 09:29:09 +0100

Hi Clemens,

Thanks for this. There are some minor editorial issues that I'll send you
off-list, but I think this is probably far enough along to submit for
provisional.

regards,

Ted

---

From: "C. Bastian | ORGAPLAN" <[email-masked]>
Date: Mon, 5 Jul 2021 13:15:07 +0200

Hi Tim, Hi Ted,

I admit that currently the "Identification" of a resource is not yet fully
described. But as Ted said, it's a provisional registration and we continue
to work on it to have a clearer scheme before a permanent registration
request. But nonetheless thanks for the feedback!

You're right: Currently the implementation is targeting the local machine
and for now, due to architectural limitations, we have no useful usage to
extend it in a way where adding an ip or domain name would enrich the
scheme. Having a non-used hostname/ip would only end up in a longer URI
which has no more value. This might change before a permanent registration.

Ted, I'm looking forward to hear your editorial improvements! Thank you
both for reading through the draft and your comments.

greetings Clemens