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

[Ted Hardie <[e-mail]>]

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

On Fri, Jul 2, 2021 at 5:54 PM 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
>