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

[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
<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 <
[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
>