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

[Ted Hardie <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <
> [e-mail]> wrote:
>
>> 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
>>
>>
>> [e-mail]
>> 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 <[e-mail]
>> >:
>> >
>> > 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). 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) 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 <
>> [e-mail]> wrote:
>> >>
>> >> 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 <
>> [e-mail]>:
>> >> >
>> >> > 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" .  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 <
>> [e-mail]> 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 <
>> [e-mail]>
>> >> >>      Scheme creator: ORGAPLAN business solutions GmbH <
>> [e-mail]>
>> >> >>
>> >> >> 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
>> >> >> [e-mail]
>> >> >> https://www.ietf.org/mailman/listinfo/uri-review
>>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
>